15. Credentials CORS et frontières de cookies

Comprendre le mécanisme

Un fetch configuré pour inclure des credentials demande au navigateur d’utiliser les éléments d’authentification applicables. Cela ne neutralise pas les règles de cookies, les restrictions de contexte ou les politiques du navigateur. Pour une lecture CORS avec credentials, le serveur doit fournir une politique compatible, notamment une origine explicite plutôt qu’un joker. Ce mécanisme ne donne toujours aucun droit sur une réservation particulière.

Raisonner et vérifier

Traitez séparément la présence du cookie, l’identité reconnue et la lecture de la réponse. Une panne peut provenir de l’une de ces étapes ; activer tout à la fois empêche le diagnostic et peut ouvrir une fuite. Même pour une origine admise, une mutation par cookie demande une protection adaptée contre les déclenchements intersites et un contrôle d’autorisation.

Include sous conditions

credentials include ne force pas l’envoi de tout cookie. Les politiques de cookies restent applicables. credentials: include demande au navigateur de considérer les credentials du flux. Cette option n’annule ni SameSite, ni portée du cookie, ni les politiques de blocage de cookies tiers du navigateur.

Origine explicite

Une réponse avec credentials exige une origine admise explicite. Le contrat de partage interdit cette généralisation. Pour une lecture CORS avec credentials, le partage doit identifier une origine admise et annoncer les credentials selon le contrat. Le joker associé à true ne fournit pas cette permission utilisable.

HttpOnly

HttpOnly contrôle la lecture JavaScript du cookie. Il ne remplace pas Secure ni les autres règles d’envoi. Cet attribut limite la lecture directe du cookie par script, pas son envoi automatique. Une page peut effectuer une demande authentifiée sans pouvoir lire la valeur du cookie lui-même.

CSRF distinct

CORS et CSRF protègent des propriétés distinctes. Une émission de mutation peut encore demander une protection dédiée. Le partage de réponse et l’intention d’une action sensible ne sont pas la même propriété. Une mutation avec cookie doit conserver sa protection CSRF même lorsque sa configuration CORS semble restrictive.

Droit métier

Le serveur décide encore des permissions métier. L’identité ne fournit pas une autorisation universelle. Une demande issue d’une origine admise et correctement authentifiée peut viser un objet tiers. Testez cette situation et refusez selon la propriété ou le tenant avant tout effet.

Cookies tiers

Un navigateur peut bloquer certains cookies tiers. Les politiques locales peuvent limiter le stockage ou l’envoi. Les politiques navigateur peuvent limiter certains cookies malgré les headers serveur. Observez le motif de blocage et le contexte réel au lieu de conclure qu’un header CORS force nécessairement leur transmission.

Reflet contrôlé

Une origine reflétée doit être vérifiée avant partage. Cela peut ouvrir la lecture à des origines non fiables. Si Origin est renvoyé dynamiquement, validez-le d’abord contre une liste maîtrisée. Une copie automatique de toute origine reçue retire le sens de cette liste et peut exposer des données personnelles.

Deux frontières

Les tests doivent couvrir autorisé et refusé. Les cas négatifs vérifient les limites annoncées. Testez lecture admise, lecture refusée et absence de droit sur un objet. Ces cas distinguent partage navigateur et autorisation serveur, qui peuvent échouer indépendamment dans le même parcours.

Cookie volé

Une valeur de cookie volée reste sensible selon son contrat. Le paramètre ne crée pas cette protection. HttpOnly ne protège pas une copie obtenue par une autre fuite. Appliquez durée, retrait et protection des traces, puis vérifiez qu’un credential retiré n’est plus accepté selon le délai annoncé.

Cache privé

Le cache ne doit pas mélanger les réponses privées. La politique de cache doit être conçue séparément. Une réponse personnelle ne doit pas être mélangée entre identités ou origines. Définissez stockage, portée et variantes ; Vary seul ne rend pas admissible une donnée qui ne doit jamais entrer dans un cache partagé.

Atelier guidé : lire, expliquer et vérifier le code

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Le couple étoile et Allow-Credentials: true ne satisfait pas une lecture CORS personnelle avec credentials. Remplacez le joker par une origine réellement admise dans ce contrat, puis vérifiez en navigateur l’envoi des cookies et la lisibilité sans oublier les protections CSRF et les droits métier.

L’échec ne signifie pas cette règle générale de cookies. Les contrôles d’identité doivent rester en place. Le contrat exige une origine explicite admise dans ce contexte. Le champ ne chiffre pas une valeur.

Travail pratique : Dans deux origines de laboratoire, testez réponse personnelle avec et sans credentials puis examinez le cookie réellement envoyé.

Critères de correction : Relevez présence du cookie, statut d’authentification et accès au corps séparément. Conservez une origine précise côté serveur et testez aussi une origine hostile, un utilisateur déconnecté et une ressource tierce.