SameSite, Domain, Path : l’ordre dans lequel ton navigateur décide d’envoyer un cookie

La séquence de décision

Un navigateur qui reçoit une requête et doit décider quels cookies y attacher suit un ordre précis : SameSite d’abord, Domain ensuite, Path en troisième, puis les attributs restants (Secure, HttpOnly n’intervenant pas dans la décision d’envoi mais dans l’accès côté script). Si SameSite exclut le cookie, le reste de la vérification ne se produit jamais. C’est ce point d’entrée qui fait toute la différence entre les trois valeurs.

None : le cookie suit partout

Avec SameSite=None (et obligatoirement Secure), le cookie part avec chaque requête vers le domaine concerné, cross-site ou non, AJAX ou navigation classique. C’est le comportement historique, celui qui a rendu possible le CSRF à grande échelle avant que Chrome ne bascule Lax en défaut en 2020. Un site B qui charge une image ou déclenche un fetch vers site A recevra le cookie de session de A si celui-ci est en None. Ce réglage se justifie pour des cas précis : SSO cross-domaine, widgets embarqués, intégrations publicitaires. Il ne devrait jamais être le réglage par défaut d’un cookie de session applicatif.

Strict : cloisonnement total

SameSite=Strict bloque l’envoi dans tout contexte cross-site, y compris quand l’utilisateur clique sur un lien externe qui pointe vers le site et change l’URL affichée dans la barre d’adresse. Conséquence concrète : un utilisateur qui arrive sur ton site depuis un lien externe (email, réseau social, autre site) n’aura pas son cookie de session envoyé sur cette première requête, même s’il était déjà connecté dans un autre onglet. Il faudra une deuxième navigation, interne cette fois, pour que le cookie reparte. C’est la protection la plus stricte contre le CSRF, mais elle a un coût en expérience utilisateur sur les parcours qui impliquent des liens entrants fréquents.

Lax : la nuance qui piège la plupart des implémentations

Lax est le défaut des navigateurs modernes depuis 2020, ce qui en fait le réglage le plus mal compris parce que personne ne l’a choisi explicitement. Deux conditions doivent être réunies simultanément pour qu’un cookie Lax parte en cross-site :

– la méthode de la requête doit être sûre (GET ou HEAD, jamais POST/PUT/PATCH/DELETE),
– la requête doit être une navigation de premier niveau, c’est-à-dire un changement effectif de l’URL affichée dans la barre d’adresse.

Cette deuxième condition élimine plus de cas qu’on ne l’imagine. Une requête GET cross-site qui laisse l’URL affichée inchangée, qu’il s’agisse d’un fetch/XHR, d’un iframe, d’une balise img ou source, ne fait pas partir le cookie, même si la méthode est sûre. Seul un clic sur un lien qui provoque une vraie navigation (l’URL dans la barre change) déclenche l’envoi. Et un formulaire POST cross-site, même soumis via un vrai lien de navigation, ne fait jamais partir un cookie Lax.

Concrètement, ça veut dire qu’un cookie Lax protège contre le CSRF classique (formulaires POST forgés sur un autre domaine) tout en préservant le confort de navigation (arriver connecté depuis un lien externe). C’est ce compromis qui en a fait le défaut raisonnable des navigateurs.

Ce que ça change dans une architecture

Trois implications directes pour qui conçoit un système de sessions ou d’authentification :

– un token CSRF reste nécessaire même avec SameSite=Lax ou Strict, parce que ces attributs protègent l’envoi du cookie, pas l’intégrité de la requête elle-même. Ils réduisent la surface, ils ne la ferment pas.
– un SSO ou une intégration multi-domaines qui dépend de None doit isoler ce cookie des cookies de session sensibles. Ne jamais mettre le cookie d’authentification principal en None pour faire fonctionner un widget tiers.
– si un parcours utilisateur dépend d’un cookie envoyé sur un appel AJAX cross-site avec Lax, ça ne marchera pas, quelle que soit la méthode. C’est une erreur d’implémentation fréquente : tester en navigation classique, ne pas tester le cas AJAX, découvrir le problème en production.

Recommandation

Recommandé : Lax par défaut pour les cookies de session applicatifs, sans exception. Strict pour les cookies protégeant une action sensible et ponctuelle (confirmation de paiement, changement de mot de passe), où la perte de confort sur la première requête est acceptable. None réservé aux cas où le cross-site est un besoin métier explicite et documenté, jamais un réglage par défaut ni un correctif rapide face à un bug d’envoi de cookie.