Que fait exactement l'en-tête Access-Control-Allow-Credentials?

167

J'essaie de comprendre comment utiliser CORS et je ne sais pas ce que fait l'en- Access-Control-Allow-Credentialstête.

La documentation dit

Indique si la réponse à la demande peut être exposée ou non lorsque l'indicateur d'informations d'identification est vrai.

Mais je ne comprends pas ce que signifie la réponse «exposée».

Quelqu'un peut-il expliquer ce que cet en-tête défini sur true (en conjonction avec l'indicateur d'informations d'identification défini sur true) fait réellement?

http-headers cors

— Nate
source

xhr.withCredential doc côté client developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/…

— Weishi Zeng

265

Par défaut, CORS n'inclut pas les cookies sur les demandes d'origine croisée. Ceci est différent des autres techniques d'origine croisée telles que JSON-P. JSON-P inclut toujours des cookies avec la demande, et ce comportement peut conduire à une classe de vulnérabilités appelée falsification de demande intersite , ou CSRF.

Afin de réduire le risque de vulnérabilités CSRF dans CORS, CORS exige que le serveur et le client reconnaissent qu'il est acceptable d'inclure des cookies dans les demandes. Cela fait des cookies une décision active, plutôt que quelque chose qui se passe passivement sans aucun contrôle.

Le code client doit définir la withCredentialspropriété sur l' XMLHttpRequestà trueafin de donner l' autorisation.

Cependant, cet en-tête à lui seul ne suffit pas. Le serveur doit répondre avec l'en- Access-Control-Allow-Credentialstête. Répondre avec cet en-tête truesignifie que le serveur autorise les cookies (ou autres informations d'identification de l'utilisateur) à être inclus dans les demandes d'origine croisée.

Vous devez également vous assurer que votre navigateur ne bloque pas les cookies tiers si vous souhaitez que les demandes d'informations d'identification croisées fonctionnent.

Notez que peu importe si vous faites des demandes de même origine ou d'origine croisée, vous devez protéger votre site de CSRF (en particulier si votre demande inclut des cookies).

— Monsur
source

J'ai clarifié la réponse pour couvrir votre question. Fondamentalement, JSON-P le fait mal et est moins sécurisé.

— monsur le

Je veux juste ajouter un peu à cela pour commenter la signification de «exposé». La spécification ne nécessite pas de pré-vol (aller-retour supplémentaire pour vérifier si le serveur autorise les informations d'identification) pour les demandes GET. Au lieu du contrôle en amont, le navigateur fera toujours la demande, en envoyant des cookies si withCredentialsest défini, mais quand il reçoit la réponse, si withCredentials a été défini, il ne livrera / exposera le résultat au javascript appelant que si la réponse a l'accès -Control-Allow-Credentials en-tête défini. S'il n'y a pas d'en-tête, il n'expose pas la réponse, ce qui la rend effectivement noire.

— heavyi5ide

@ heavyi5ide, Oui, même si le navigateur n'expose pas la réponse au code client, la requête avec cookie était toujours envoyée (pour les requêtes non contrôlées en amont). Donc CSRF serait toujours fait.

— Pacerier

Comme il s'agit d'une réponse très populaire, je vais ajouter une autre information importante: en plus de configurer correctement vos en-têtes de demande et de réponse, vous devez également vous assurer que votre navigateur ne bloque pas les cookies tiers si vous veulent que les demandes d'informations d'identification croisées fonctionnent. Voir stackoverflow.com/a/16634887/2970321

— alexw

C'est une réponse si claire que quiconque la lit pour la première fois peut comprendre et corriger son code qui ne semble pas bien fonctionner avec les cookies. Merci!

— asgs