Avec CORS, pourquoi les serveurs déclarent-ils quels clients peuvent lui faire confiance, au lieu que les clients déclarent à quels serveurs ils font confiance?

-1

Il y a quelque chose à propos de Cross Origin Resource Sharing (CORS) que je n'ai jamais vraiment compris, à savoir qu'avec une requête HTTP d'origine croisée, ce n'est pas le client qui décide du serveur auquel il veut faire confiance; à la place, le serveur déclare (dans l'en-tête de réponse Access-Control-Allow-Origin) qu'un ou plusieurs clients particuliers (origines) lui font confiance. Un navigateur compatible CORS fournira uniquement la réponse du serveur à l'application si le serveur indique que le client approuve le serveur. Cela semble être une manière inverse d'établir une relation d'approbation entre deux parties HTTP.Avec CORS, pourquoi les serveurs déclarent-ils quels clients peuvent lui faire confiance, au lieu que les clients déclarent à quels serveurs ils font confiance?

Ce qui aurait plus de sens pour moi est un mécanisme similaire à celui-ci: Le client déclare une liste d'origines auxquelles il fait confiance; par exemple, via un élément fictif <meta allow-cross-origin="https://another-site:1234"/> dans le <head>. (Bien sûr, un navigateur doit s'assurer que ces éléments sont en lecture seule et ne peuvent pas être supprimés, modifiés ou augmentés via des scripts.)

Qu'est-ce que je ne comprends pas au sujet de CORS? Pourquoi une déclaration côté client d'origine de confiance ne fonctionnerait-elle pas? Pourquoi les serveurs vérifient-ils quels clients (origines) peuvent faire confiance à leurs réponses? Qui est réellement protégé de qui par CORS? Protège-t-il le serveur ou le client?

(Ce sont beaucoup de questions. J'espère qu'il est clair que je ne m'y attendais pas une réponse à chacun d'entre eux, mais juste une réponse qui souligne mon incompréhension fondamentale.)

Source

2016-08-31 stakx

Pour le downvoter, j'apprécierais un indice ce qui ne va pas avec ma question. Je suis heureux de l'éditer, d'expliquer plus loin, ou de rétracter la question si c'est vraiment inapproprié. – stakx

Le site Web hébergeant le JavaScript indique implicitement qu'il fait confiance au site auquel il tente de récupérer les données en demandant des données à partir de cette URL en premier lieu. – Quentin

"le serveur déclare (dans l'en-tête de réponse Access-Control-Allow-Origin) qu'un ou plusieurs clients particuliers (origines) lui font confiance" - Non, il déclare qu'il approuve ces origines, et non qu'elles lui font confiance. – Quentin

client n'a rien à voir avec ça. Avec un en-tête CORS, vous dites au client à quels autres serveurs je fais confiance. Ceux-ci peuvent alors partager vos ressources et le client ne vous dérange pas. Par exemple si vous avez deux domaines vous dites au client alors laissez vos ressources être utilisées par votre deuxième site Web, vous ne dites pas que je vous fais confiance en tant que client.

Donc vous protégez le serveur, pas le client. Vous ne voulez pas que les points de terminaison API AJAX soient accessibles par des scripts hébergés n'importe où dans le monde.

Un client n'a rien à gagner/perdre de cela. C'est seulement une protection pour les serveurs parce qu'utiliser AJAX toutes les URLs sont clairement visibles à quiconque et si ce n'était pas pour cette protection, tout le monde pourrait aller de l'avant avec son API, seuls les serveurs ont à perdre pour pouvoir décider qui peut utiliser leurs ressources.

Source

2016-08-31 10:07:43

La question est d'abuser du terme "client" pour signifier "Le site Web qui héberge la page contenant le JavaScript qui amène le client à lancer la demande" – Quentin

Vous dites que CORS est réellement là pour protéger un serveur invité à produire une réponse, pas le client qui fait la demande. Mais cela n'a pas de sens pour moi. Pourquoi le CORS serait-il nécessaire? Un serveur HTTP peut simplement regarder qui a fait la requête, puis envoyer un code d'état '2xx' /' 3xx' ou (par exemple) un '401 Unauthorized'. Mais avec CORS, je comprends que le serveur va produire une réponse de toute façon, mais avec un en-tête qui permet au navigateur côté client de décider si/comment traiter la réponse. Étant donné que ma compréhension est correcte, comment CORS ajoute-t-il la protection du serveur à une simple réponse «401»? – stakx

Ok donc vous ne pensez pas que vous pourriez vouloir partager vos ressources entre 2 domaines différents que vous possédez? Si c'est le cas, CORS n'est pas pour vous. CORS est là pour faciliter le contournement de la restriction de partage lorsque vous avez l'intention de le faire. –

Avec CORS, pourquoi les serveurs déclarent-ils quels clients peuvent lui faire confiance, au lieu que les clients déclarent à quels serveurs ils font confiance?

Répondre

Questions connexes