Résumé

  • draft-ietf-httpbis-layered-cookies-02 précise que Path règle la sélection d’un cookie, mais ne fournit aucune protection d’intégrité: une réponse issue d’un chemin peut poser un cookie destiné à un autre.
  • Le cloisonnement réel doit séparer l’hôte ou vérifier cryptographiquement et côté serveur la provenance, la session et l’autorisation. Le navigateur qui renvoie un cookie ne signe pas le mandat de l’application.

L’équipe finance avait son cookie sous /finance; le support avait le sien sous /support. Les tableaux d’architecture dessinaient deux boîtes, deux propriétaires et deux niveaux de privilège. Pourtant une réponse du support pouvait poser un cookie portant Path=/finance.

Le navigateur appliquait correctement les règles de sélection. C’était l’architecture qui avait confondu un filtre de routage avec un mur d’intégrité.

La révision 02 de Cookies: HTTP State Management Mechanism a été publiée le 21 mai 2026 comme Internet-Draft actif du groupe HTTP de l’IETF et expire le 22 novembre 2026. Elle vise la voie des standards et dit qu’elle rendrait obsolètes RFC 6265 et 6265bis si elle était approuvée. Elle reste un travail en cours, non un RFC, un audit des navigateurs ou une preuve de déploiement.

Path répond à «quand envoyer», pas à «qui peut écrire»

Path limite le renvoi du cookie aux URL dont le chemin correspond. Cette fonction est utile pour éviter d’envoyer tout état à toute ressource d’un hôte. Elle ne réserve pas la création du cookie au service logé sous ce chemin.

Le projet avertit donc que des services qui ne se font pas confiance ne devraient pas habiter des chemins différents du même hôte tout en utilisant des cookies pour des données sensibles. Le récepteur ne peut pas déduire de Path=/finance que l’application finance a créé la valeur.

La conclusion sûre est un tuple: hôte, Domain, Path, nom, date de création, canal de pose, attributs, heure d’envoi et endpoint destinataire. Même ce tuple décrit le parcours visible; la session côté serveur doit encore reconnaître la valeur.

Une séparation organisationnelle sans séparation de la surface d’écriture n’est qu’une convention. Si l’un des services est compromis, la convention ne limite pas son pouvoir protocolaire.

Domain peut ouvrir l’écriture aux frères

Sans Domain, le cookie est lié à l’hôte. Avec Domain, il peut être renvoyé au domaine indiqué et à ses sous-domaines admissibles. Les règles de suffixe public empêchent des extensions absurdes vers un registre partagé, mais elles ne rendent pas les applications sœurs dignes de confiance.

Un serveur foo.site.example peut poser un cookie pour site.example; le navigateur le renverra à bar.site.example. Le projet souligne que bar peut être incapable de distinguer cette valeur de celle qu’il a créée.

Le problème est la provenance. Le nom et la portée indiquent où l’état circule, pas quelle équipe en est l’auteur. Une politique IAM qui traite tous les sous-domaines comme un seul principal parce qu’ils partagent des cookies transfère au DNS une autorité que le DNS n’a pas promise.

Les cookies host-only et le préfixe __Host- réduisent la surface. Ils ne remplacent pas la validation de session, la rotation ni l’autorisation de l’opération.

Les ports ne cloisonnent pas les cookies

L’origine web distingue schéma, hôte et port. Le mécanisme Cookie n’isole pas par port. Deux services sur le même hôte mais sur des ports différents peuvent recevoir la même valeur alors que d’autres politiques du navigateur les considèrent comme des origines distinctes.

Cette asymétrie doit apparaître dans les modèles de menace. Déplacer une application privilégiée vers un autre port ne suffit pas si le cookie de session reste à portée de l’hôte. Le port peut séparer des processus sans séparer l’autorité ambiante.

Les journaux doivent conserver le port de pose et le port de réception, même si la clé de stockage ne les distingue pas. Une anomalie sur un seul port peut venir d’une valeur écrite ou manipulée ailleurs.

La solution forte est une frontière d’hôte, complétée par un état serveur lié au contexte attendu. La solution faible est de dessiner une ligne sur un diagramme.

Secure protège le transport sans certifier l’auteur

Secure demande au navigateur de ne renvoyer le cookie que sur un canal sécurisé, en pratique HTTP sur TLS. Cette contrainte est importante mais limitée.

TLS protège l’échange avec son pair selon ses propres garanties. Il ne prouve pas comment le cookie est entré dans le magasin, quel frère l’a posé, si la valeur a été révoquée ou si l’humain voulait l’action. Le projet conserve aussi l’avertissement historique selon lequel Secure ne fournit pas, à lui seul, toute l’intégrité face au modèle d’attaque actif du protocole Cookie.

Dire «le cookie est arrivé en HTTPS» est une observation. Dire «l’application l’a émis et l’utilisateur a autorisé» ajoute deux autorités absentes.

Le serveur doit donc valider le format, la signature ou l’opacité attendue, l’état de session, la fraîcheur, le principal et la permission propre à la requête.

HttpOnly, SameSite et préfixes ont chacun leur mandat

HttpOnly limite l’accès par des API non HTTP, notamment JavaScript dans le navigateur. Il ne rend pas la valeur inconnue du serveur, ne prouve pas son origine et n’empêche pas son ajout automatique aux requêtes admissibles.

SameSite modifie les conditions d’envoi dans des contextes intersites. Il peut réduire des scénarios CSRF, mais ne certifie ni identité, ni consentement, ni résultat.

Les préfixes __Secure- et __Host- imposent des conditions de pose supplémentaires. Ils peuvent prévenir des erreurs fréquentes, sans transformer la présence du cookie en reçu d’authentification complet.

Empiler ces contrôles est raisonnable. Les fusionner en un voyant «sûr» ne l’est pas. La revue doit nommer la menace couverte et le risque résiduel de chaque attribut.

L’autorité ambiante précède l’intention

Le navigateur joint automatiquement les cookies aux requêtes qui correspondent. Une partie distante peut désigner l’URL par redirection ou formulaire sans connaître le secret; le navigateur fournit néanmoins l’état.

Le serveur reçoit alors une requête portant une session. Sans jeton anti-CSRF, preuve de fraîcheur ou confirmation propre à l’action, il peut confondre autorité ambiante et intention de l’utilisateur. L’attaquant choisit l’action, le navigateur apporte la credential.

La présence du Cookie soutient une seule affirmation: l’agent utilisateur a sélectionné et envoyé ces valeurs sous ses règles courantes. L’identité et l’autorisation sont des décisions du serveur. Le résultat exige encore un commit et un reçu.

Cette chaîne rend les responsabilités visibles. Elle empêche qu’un mécanisme de transport d’état devienne constitution silencieuse de toutes les applications d’un domaine.

Expiration et suppression ne prouvent pas la révocation

Expires et Max-Age fixent une durée maximale. L’agent peut supprimer plus tôt pour quota, mémoire, confidentialité ou choix utilisateur. L’absence ultérieure n’établit donc pas automatiquement un logout ou une révocation serveur.

La présence n’établit pas non plus la validité. Le serveur peut avoir révoqué ou remplacé la session. Il faut observer magasin client et registre serveur séparément.

Pour supprimer côté client, la réponse passée doit correspondre au Domain et au Path du cookie visé. Un handler de déconnexion qui utilise le bon nom mais le mauvais tuple peut laisser un autre cookie actif.

Une déconnexion fiable invalide d’abord l’autorité serveur, puis tente la suppression exacte et vérifie les requêtes suivantes. Le succès de Set-Cookie n’est pas, à lui seul, le succès de la révocation.

Sources et limites

Le dossier gelé contient la révision 02, ses pages Datatracker, le groupe HTTP, RFC 6265 et 6265bis, HTTP, TLS 1.3, les définitions WHATWG de l’origine et des URL, le registre IANA et la Public Suffix List.

Ces sources établissent le texte et ses limites, pas la conformité d’un navigateur, une attaque réelle ou le comportement d’un service nommé. L’exemple finance/support est construit pour tester la frontière.

Sources