Ce qui casse vraiment avec SameSite Lax vs Strict vs None

Quelle est la différence entre SameSite Lax vs Strict vs None ?

Les navigateurs lisent SameSite Lax vs Strict vs None comme trois réponses à une seule question : quelles requêtes cross-site peuvent transporter ce cookie. Le RFC 6265bis donne les trois dans un seul paragraphe de la section 4.1.2.7 : "If the 'SameSite' attribute's value is 'Strict', the cookie will only be sent along with 'same-site' requests. If the value is 'Lax', the cookie will be sent with same-site requests, and with 'cross-site' top-level navigations, as described in Section 5.6.7.1. If the value is 'None', the cookie will be sent with same-site and cross-site requests."

Le brouillon en vigueur est draft-ietf-httpbis-rfc6265bis-22, daté du 1er décembre 2025, édité par Bingler, West et Wilander, et marqué "Obsoletes: 6265 (if approved)". L'attribut limite la portée par site plutôt que par origine, donc https://www.site.example et https://api.site.example sont le même site, et savoir si deux hôtes partagent un site se tranche avec la public suffix list plutôt qu'avec le domaine enregistrable seul.

Qu'autorise Lax que Strict interdit ?

Lax autorise exactement une classe de requête en plus : une navigation de premier niveau cross-site qui utilise une méthode HTTP sûre. Le RFC énonce la dérogation et son intention ensemble, en appelant Lax "a drop-in mechanism that mitigates the risk of CSRF attacks" qui "sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a 'safe' (in the [HTTP] sense) HTTP method."

MDN en fait le test que vous appliquez en pratique. Une navigation de premier niveau "essentially means that the request causes the URL shown in the browser's address bar to change", ce qui couvre un lien cliqué, une affectation à document.location et une soumission de <form>, et exclut "requests made using the fetch() API, or requests for subresources from <img> or <script> elements, or navigations inside <iframe> elements." La moitié méthode sûre "excludes POST, PUT, and DELETE."

Le RFC est honnête sur ce que Lax ne vous achète pas. "Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like POST), but does not offer a robust defense against CSRF as a general category of attack", puisque "Attackers can still pop up new windows or trigger top-level navigations in order to create a 'same-site' request".

Quel est le défaut documenté de Chrome pour SameSite ?

Chrome traite un cookie sans attribut SameSite comme Lax, et documente une exception délibérée. La référence de Google énonce la règle : "If you send a cookie without specifying its SameSite attribute, the browser treats that cookie as if it were set to SameSite=Lax." La même page ajoute l'exception dans un encadré d'avertissement : "Chrome's default behavior is slightly more permissive than an explicit SameSite=Lax, because it lets sites send some cookies on top-level POST requests. For details, see the blink-dev announcement. This is intended as a temporary mitigation."

Cette page porte une date de dernière mise à jour au 7 mai 2019 et un tableau de compatibilité qui liste Chrome 80 et Edge 86 pour le changement de défaut, Firefox derrière un drapeau, et Safari non pris en charge. L'IETF a depuis formalisé la dérogation que Chrome qualifie de temporaire. Le RFC 6265bis la nomme "Lax-allowing-unsafe" et la spécifie : les user agents "MAY apply 'Lax-allowing-unsafe' enforcement only to cookies that did not explicitly specify a SameSite attribute", ils "SHOULD restrict the enforcement to cookies which were created recently", et "Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit." MDN donne le même chiffre côté navigateur : sous un Lax par défaut, "cookies are also included in POST requests, as long as they were set no more than two minutes before the request was made."

Deux conséquences en découlent, et les deux surprennent. Écrire SameSite=Lax explicitement est plus strict que de ne rien écrire, parce que le RFC n'applique Lax-allowing-unsafe qu'aux cookies dont le drapeau a été mis à "Default" par absence. Et "Lax-allowing-unsafe is not a distinct value of the SameSite attribute", donc aucune chaîne ne permet de le demander.

La spécification traite une faute de frappe de la même façon. "If the 'SameSite' attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to 'Lax'." Un cookie envoyé avec SameSite=Laxx n'est pas rejeté ; il est silencieusement traité comme non défini.

Pourquoi SameSite=None doit-il porter Secure ?

Un cookie qui affirme SameSite=None sans Secure est jeté, et le RFC place cette règle dans l'algorithme de stockage plutôt que dans un conseil. L'étape 19 de la section 5.7 se lit : "If the cookie's 'same-site-flag' is 'None', abort this algorithm and ignore the cookie entirely unless the cookie's secure-only-flag is true."

La référence de Google dit la même chose aux développeurs, "When you create cross-site cookies using SameSite=None, you must also set them to Secure for the browser to accept them", et donne l'en-tête complet :

Set-Cookie: widget_session=abc123; SameSite=None; Secure

La formulation de MDN est tout aussi sèche : pour None, "The Secure attribute must also be set when using this value." Aucun avertissement de console ne ressemble à un avertissement pour la plupart des gens, parce que le cookie n'est simplement jamais stocké. Si une intégration cross-site fonctionne sur votre machine et échoue en production, vérifiez d'abord si la réponse a posé SameSite=None sur du HTTP en clair.

Partitioned se superpose à cette règle, il ne la remplace pas. Les navigateurs n'acceptent cet attribut qu'aux côtés de SameSite=None, ce que couvre comment les cookies partitionnés CHIPS donnent à chaque site son propre bocal.

Qu'est-ce qui casse dans chaque mode ?

Le RFC illustre l'échec de Strict par un scénario plutôt que par une règle. Une personne qui lit son courrier sur https://site.example clique sur un lien vers https://projects.example/secret/project : "if https://projects.example has marked their session cookies as SameSite=Strict, then this cross-site navigation won't send them along with the request. https://projects.example will render a 404 error to avoid leaking secret information, and the user will be quite confused." Strict fait ressembler chaque lien entrant venu de la recherche, du courrier, de la messagerie et des réseaux sociaux à une visite déconnectée au premier affichage.

Le remède prescrit tient en deux cookies plutôt qu'un, "one conceptually granting 'read' access, another granting 'write' access. The latter could be marked as SameSite=Strict, and its absence would prompt a reauthentication step before executing any non-idempotent action. The former could be marked as SameSite=Lax."

Lax casse un ensemble plus étroit de choses, et le RFC nomme la plus vive : "the concluding step of a login flow may involve a cross-site top-level POST request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login." Sous un Lax explicite, ce cookie est exclu pour cause de méthode, "resulting in an unrecoverable failure of the whole login flow." L'authentification unique et les retours de paiement échouent de la même façon.

None ne casse rien par règle et tout par politique. Le RFC identifie les cas qui en ont besoin, "content intended for embedding in cross-site contexts (social networking widgets or commenting services, for instance) will not have access to same-site cookies. Cookies which are required in these situations should be marked with SameSite=None", et ajoute que "some forms of Single-Sign-On might require cookie-based authentication in a cross-site context". Un cookie SameSite=None; Secure est un cookie third-party dans tous les sens qui comptent pour les contrôles de confidentialité d'un navigateur, donc il hérite de chacune des restrictions que ces contrôles appliquent. Cet héritage est toute l'histoire de seul le domaine décide entre cookies first-party et third-party, et de ce que la limite Safari de 7 jours sur les cookies restreint vraiment.

Une réponse cross-site peut-elle poser un cookie Lax ou Strict ?

Non, et cette règle est distincte de la livraison. La section 4.1.2.7 indique que "The 'SameSite' attribute affects cookie creation as well as delivery. Cookies which assert 'SameSite=Lax' or 'SameSite=Strict' cannot be set in responses to cross-site subresource requests, or cross-site nested navigations. They can be set along with any top-level navigation, cross-site or otherwise."

Un widget embarqué chargé dans une <iframe> sur la page de quelqu'un d'autre ne peut donc écrire aucun cookie Lax, quelles que soient ses intentions. Le seul cookie qu'il peut écrire est SameSite=None; Secure. Les scripts d'analytics servis depuis un domaine fournisseur partagé heurtent cette règle en permanence, ce qui explique en partie pourquoi l'hébergement first-party des scripts et la décoration de liens que vise Apple sont passés au centre de la conception de la mesure.

Questions fréquentes

Quelle valeur SameSite un cookie de session doit-il utiliser ?

Lax pour un cookie de session qui doit survivre à un lien entrant, puisque le RFC appelle Lax un "drop-in mechanism that mitigates the risk of CSRF attacks". Strict pour tout ce qui garde une action modifiant l'état, en suivant le motif à deux cookies du RFC où l'absence de la moitié Strict "would prompt a reauthentication step before executing any non-idempotent action."

Omettre SameSite revient-il à écrire SameSite=Lax ?

Pas dans Chrome. Google documente le défaut comme plus permissif : il "lets sites send some cookies on top-level POST requests." Le RFC 6265bis restreint ce comportement Lax-allowing-unsafe aux "cookies that did not explicitly specify a SameSite attribute", avec une limite d'âge recommandée de "2 minutes or less". Écrire l'attribut vous donne un comportement plus strict que de le laisser de côté.

SameSite=None exige-t-il HTTPS ?

Oui, indirectement, parce qu'il exige Secure et que les cookies Secure sont confinés aux protocoles sécurisés. L'étape 19 du RFC 6265bis jette le cookie sans appel : l'ignorer "unless the cookie's secure-only-flag is true."

SameSite arrête-t-il le CSRF à lui seul ?

Non. Le RFC dit que Lax "does not offer a robust defense against CSRF as a general category of attack" et oriente les développeurs vers "more completely mitigate CSRF through a session management mechanism". Les recommandations de Google ajoutent que "Neither Strict nor Lax is a complete solution for your site's security."

Que se passe-t-il si j'envoie une valeur SameSite invalide ?

Elle est traitée comme si vous n'aviez rien envoyé. Selon la section 4.1.2.7, une valeur "other than these three known keywords" reçoit "a default enforcement mode that is equivalent to 'Lax'", et l'algorithme de stockage met le same-site-flag du cookie à "Default". La casse n'a pas d'importance, puisque le RFC reconnaît "None", "Strict" et "Lax" sans tenir compte de la casse.

SameSite se décide-t-il par domaine ou par site ?

Par site, ce qui est plus large qu'une origine et plus étroit qu'un domaine. Les sous-domaines d'un même site enregistrable sont same-site entre eux, et la référence de Google pointe la frontière qui piège les gens : la public suffix list "doesn't just depend on top-level domains like .com, but can also include services like github.io", donc your-project.github.io et my-project.github.io sont des sites distincts.

Pourquoi les liens venus d'un e-mail ou d'une recherche cassent-ils avec SameSite=Strict ?

Le RFC décrit exactement ce cas : un utilisateur qui lit ses e-mails clique sur un lien vers un site dont les cookies de session portent SameSite=Strict, et la navigation cross-site n'envoie pas ces cookies. Le site de destination affiche une erreur 404 pour ne pas révéler de données, et l'utilisateur voit ce qui ressemble à une page déconnectée au premier chargement. La solution proposée par le RFC consiste à utiliser deux cookies plutôt qu'un, le cookie d'écriture étant seul marqué Strict et le cookie de lecture marqué Lax.

Pourquoi un flux de connexion échoue-t-il avec SameSite=Lax ?

Certains flux de connexion se terminent par un POST cross-site de premier niveau vers un point de terminaison qui attend un cookie créé récemment contenant des données de transaction. Un cookie SameSite=Lax explicite est exclu de cette requête parce que POST n'est pas une méthode sûre, ce que le RFC décrit comme "unrecoverable failure of the whole login flow". L'authentification unique et les retours de paiement échouent pour la même raison.

Un widget dans un iframe cross-site peut-il poser un cookie Lax ?

Non. La section 4.1.2.7 précise que les cookies portant SameSite=Lax ou SameSite=Strict ne peuvent pas être posés en réponse à des requêtes cross-site de sous-ressources ni à des navigations imbriquées cross-site, ce qui couvre un iframe intégré sur la page d'un autre site. Le seul cookie qu'un tel widget peut poser est SameSite=None avec Secure.

Quel est le rapport entre l'attribut Partitioned et SameSite=None ?

Partitioned se superpose à SameSite=None au lieu de le remplacer. Les navigateurs n'acceptent l'attribut Partitioned qu'accompagné de SameSite=None, ce qui permet à CHIPS de donner à chaque site son propre pot à cookies tout en gardant les exigences None et Secure.