FreeToGenerate.com

Les règles qu'appliquent les navigateurs vivent dans un brouillon expiré en juin 2026.

L'en-tête Set-Cookie

Ce qu'un navigateur en fait

Un navigateur rejettera purement et simplement ce cookie

Il n'est pas stocké et aucune erreur n'est affichée. La requête suivante part simplement sans cookie, et c'est pourquoi ce type d'erreur se manifeste d'ordinaire par une connexion qui cesse de fonctionner sans explication.

Nom du cookie
__Host-session
Préfixe du nom
__Host-
  • Un cookie __Host- doit avoir exactement Path=/. Tout autre chemin, ou l'absence de Path, entraîne le rejet.

D'où viennent les règles

attributs
8
dans la RFC publiée
6
seulement dans le brouillon
1
définis ailleurs
1

La RFC 6265, la norme publiée en 2011, contient le mot SameSite exactement zéro fois, et ni __Host- ni __Secure- n'y figurent. Les trois sont dans draft-ietf-httpbis-rfc6265bis, un Internet-Draft jamais devenu RFC — et sa révision 22, l'actuelle, porte la date d'expiration du 4 juin 2026. Les navigateurs l'implémentent tout de même. Voilà l'état réel de la normalisation des cookies, vérifiable dans deux documents.

Les préfixes s'appliquent par rejet, non par avertissement. Un cookie __Host- doit être Secure, doit avoir Path=/ et ne doit pas avoir de Domain ; un __Secure- n'a besoin que de Secure. Une seule erreur et le cookie est écarté en silence : la panne ressemble alors à un bug de votre application plutôt qu'à un problème d'en-tête.

Les attributs et le document qui définit chacun

AttributValeurDéfini dans
ExpiresEn prend uneRFC 6265
Max-AgeEn prend uneRFC 6265
DomainEn prend uneRFC 6265
PathEn prend uneRFC 6265
SecureAucuneRFC 6265
HttpOnlyAucuneRFC 6265
SameSiteEn prend une6265bis (brouillon)
PartitionedAucuneUn autre brouillon

Règles citées de la RFC 6265 et de draft-ietf-httpbis-rfc6265bis-22. Rien n'est envoyé : l'analyse a lieu dans cet onglet.

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

  1. 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.
  2. 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.
  3. 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.