Aussi disponible en : English · Español · Português · العربية
En-tête Set-Cookie : attributs, SameSite et le préfixe __Host-
Assemblez un en-tête de cookie ou collez-en un, et voyez si le navigateur va le stocker ou le jeter sans rien dire.
Qu'est-ce que l'en-tête Set-Cookie ?
Set-Cookie est la façon dont un serveur demande à un navigateur de retenir quelque chose. L'en-tête est un nom et une valeur suivis d'attributs qui décident de la durée de vie du cookie, des requêtes qui l'emportent et de la possibilité pour un script de le lire : Expires, Max-Age, Domain, Path, Secure, HttpOnly et SameSite.
L'endroit où ces règles sont écrites surprend davantage que les règles elles-mêmes. La RFC 6265, la norme publiée en 2011, définit les six premiers. Elle contient le mot SameSite exactement zéro fois, et ni __Host- ni __Secure- n'y figurent. Les trois vivent dans draft-ietf-httpbis-rfc6265bis, un Internet-Draft jamais promu au rang de RFC — et sa révision 22, l'actuelle, porte la date d'expiration du 4 juin 2026.
Tous les navigateurs implémentent le brouillon. Les règles qui décident si votre cookie de session est sûr se trouvent donc, formellement, dans un document expiré, tandis que le texte normatif n'en dit rien. Les deux faits se vérifient dans deux fichiers, et cette page indique de quel document provient chaque attribut.
Comment l'utiliser
- Saisissez ou collez l'en-tête. La seule valeur du champ, sans le préfixe Set-Cookie:. Les boutons d'attributs et le champ de texte ne font qu'un : agir sur l'un réécrit l'autre.
- Lisez d'abord le verdict. La première ligne dit si le navigateur stockera le cookie ou le rejettera, car ce sont les deux seules issues qui comptent et la seconde est invisible à l'exécution.
- S'il est rejeté, utilisez le bouton de correction. Il réécrit le cookie avec le préfixe __Host- et les trois attributs qu'il exige, ce qui est la forme la plus solide qu'un cookie puisse prendre.
Les préfixes s'appliquent en silence
Un cookie dont le nom commence par __Host- doit porter Secure, doit avoir exactement Path=/ et ne doit pas porter d'attribut Domain. Un cookie commençant par __Secure- n'a besoin que de Secure. Manquez l'un de ces points et le navigateur n'avertit ni ne journalise quoi que ce soit : il refuse simplement de stocker le cookie, et la requête suivante arrive sans lui. Voilà pourquoi ce type d'erreur se présente d'ordinaire comme une connexion qui a cessé de fonctionner, et non comme un problème d'en-tête.
Les deux préfixes ne sont pas la même règle, et les confondre est l'erreur courante. __Secure- autorise un Domain et n'importe quel Path ; __Host- interdit le Domain précisément parce que c'est ce qui rattache le cookie à un hôte exact au lieu de le partager avec tous les sous-domaines. Si un sous-domaine que vous ne maîtrisez pas entièrement peut poser des cookies, cette différence est toute la frontière de sécurité.
Les préfixes sont en outre sensibles à la casse, selon les termes mêmes de la spécification. Un nom commençant par __host- en minuscules ne reçoit aucune protection tout en donnant exactement l'impression inverse : cette page le signale donc comme un constat à part plutôt que de se taire.
SameSite=None suit le même schéma : il exige Secure, faute de quoi le cookie est rejeté. Cela piège sans cesse les parcours intégrés et intersites, car la valeur qui paraît la plus permissive est celle assortie d'une exigence supplémentaire.
Ce que cette page ne fait pas
Elle vérifie un en-tête isolé. Elle ne peut pas savoir si vous êtes en HTTPS, et les cookies Secure sont écartés en HTTP simple quelle que soit la correction apparente de l'en-tête ; elle ne connaît pas non plus votre domaine, donc elle ne peut pas dire si le Domain que vous posez est un domaine que vous avez le droit de poser.
Elle n'impose pas davantage Partitioned, l'attribut de CHIPS. Partitioned apparaît zéro fois dans la révision 22 de 6265bis — il relève d'un autre brouillon — si bien que cette page l'indique comme défini ailleurs plutôt que de laisser croire qu'il appartient au même document que le reste.
Enfin, elle rapporte ce que disent les spécifications, pas ce que fait votre framework. La plupart posent les cookies via une fonction utilitaire dotée de ses propres valeurs par défaut, et plusieurs mettent SameSite=Lax à votre place, que vous l'ayez demandé ou non. Vérifier l'en-tête réellement envoyé est l'étape utile ; cette page vous dit ce que cet en-tête signifie.
Pourquoi est-ce gratuit ?
Les règles tiennent en une petite table et l'analyse a lieu dans votre propre navigateur. Rien de ce que vous tapez n'est envoyé, rien n'est journalisé, et il n'y a aucun compte à créer.
Sans inscription, sans limite, et sans filigrane sur ce que vous copiez.