Validateur de préfixes de cookies HTTP｜Règles __Host- et __Secure- ligne par ligne

Collez vos en-têtes Set-Cookie et l'outil vérifie chaque ligne au regard des règles RFC 6265bis pour les préfixes __Host- et __Secure-. Chaque ligne reçoit une pastille PASS / FAIL, et les lignes en échec précisent quelle exigence a été rompue, à côté d'un tableau des attributs analysés : Path, Domain, Secure, HttpOnly, SameSite. Sans serveur : il suffit de coller et de lire.

💡 À propos de cet outil

__Host- et __Secure- sont des préfixes de cookie : des préfixes de nom particuliers qui amènent le navigateur à imposer des exigences d'attributs. Si le nom d'un cookie commence par l'un d'eux sans que les exigences soient remplies, le navigateur ignore silencieusement tout l'en-tête Set-Cookie. C'est précisément ce rejet silencieux qui transforme un « j'ai posé __Host-session mais l'utilisateur n'est jamais connecté » en un après-midi de débogage.

Les deux préfixes demandent des choses différentes. __Secure- exige seulement l'attribut Secure. __Host- est plus strict : en plus de Secure, il impose Path=/ (exactement la racine) et aucun attribut Domain. Supprimer Domain fixe le cookie à l'hôte exact qui l'a émis, ce qui bloque le cookie tossing entre sous-domaines : un attaquant sur evil.example.com ne peut pas écrire un cookie qui parviendra à app.example.com. Dès que vous placez un CDN ou un répartiteur de charge devant une architecture multi-hôtes, c'est cette distinction que l'on oublie le plus souvent.

Le contexte réglementaire francophone rend cette vérification d'autant plus utile : le RGPD et les lignes directrices de la CNIL imposent de maîtriser quels cookies sont déposés et sur quel périmètre. Verrouiller un cookie de session avec __Host- documente techniquement cette portée, et l'outil reçoit un lot complet de lignes Set-Cookie, détecte le préfixe de chacune et applique uniquement les règles que ce préfixe déclenche, avec des motifs tels que « __Host- ne doit pas inclure l'attribut Domain ».

🧐 Questions fréquentes

Quelle différence entre __Host- et __Secure- ? La sévérité. __Secure- ne requiert que l'attribut Secure. __Host- requiert Secure, plus Path=/ exact et aucun attribut Domain. __Host- offre la plus forte garantie de liaison à un hôte.

Les préfixes sont-ils sensibles à la casse ? Non. Le navigateur traite __Host- et __host- (minuscules) comme le même préfixe et impose les mêmes règles. RFC 6265bis est passé à une comparaison insensible à la casse pour fermer un contournement : un serveur qui compare les noms de cookies sans tenir compte de la casse pourrait sinon être trompé par une variante en minuscules envoyée sans Secure. L'outil applique lui aussi les règles sans tenir compte de la casse.

Pourquoi un cookie __Host- avec Path=/api échoue-t-il ? __Host- exige Path=/, exactement la racine. Un sous-chemin comme /api rompt l'exigence et le navigateur jette le cookie. S'il vous faut un chemin restreint, utilisez __Secure-.

Comment sont traitées les lignes sans préfixe ? Une ligne sans préfixe privilégié n'a aucune exigence à vérifier : elle est marquée PASS et étiquetée « (sans préfixe) ». Le tableau d'attributs s'affiche tout de même pour examiner ce qui a été réellement défini.

Une donnée que je colle quitte-t-elle ma machine ? Non. Chaque ligne est analysée dans votre navigateur et les en-têtes Set-Cookie que vous collez ne sont jamais envoyés à un serveur ; coller des noms et valeurs de cookies réels de production reste local.

📚 Pourquoi la règle est dans le nom, et non dans un attribut

L'astuce derrière __Host- et __Secure- est que l'exigence est inscrite dans le nom plutôt que portée par un attribut. Un en-tête Set-Cookie part du serveur vers le navigateur avec tous ses attributs, mais quand le navigateur renvoie ensuite le cookie (l'en-tête de requête Cookie), seuls le nom et la valeur voyagent : Secure, Path et les autres ont disparu. Le serveur ne peut donc pas inspecter un cookie entrant pour confirmer qu'il a bien été stocké avec Secure. Le préfixe comble cette faille : encodez l'exigence dans le nom, et la simple arrivée d'un cookie nommé __Host-session prouve que le navigateur a imposé Secure et la liaison à l'hôte lors du stockage, car la spécification l'oblige à écarter en silence tout Set-Cookie non conforme. Garantir la sécurité par une convention de nommage plutôt que par un nouvel attribut explique aussi pourquoi les préfixes ont pu être déployés de façon rétrocompatible : ils s'appuient sur le format de cookie existant sans changer un seul octet de sa grammaire.