Résumé

  • Le RFC 10025 impose un profil prudent aux producteurs de cookies et un traitement plus tolérant aux consommateurs. Un champ Set-Cookie correct peut néanmoins être ignoré, refusé, normalisé, remplacé ou supprimé avant toute requête ultérieure.
  • Un cookie conservé n’est pas nécessairement envoyé, et un cookie envoyé n’autorise pas une opération. Un reçu de cycle de vie doit relier les verdicts successifs sans journaliser la valeur secrète.

Dans un parcours d’authentification reconstruit, la réponse est impeccable : code attendu, TLS actif, deux lignes Set-Cookie distinctes et attributs apparemment conformes. Le test de déploiement conclut que la session est créée. La requête suivante arrive anonyme.

Il manque une observation, pas forcément un paquet. Le client a pu refuser une condition de préfixe, appliquer une politique locale, remplacer une entrée portant le même nom, fermer la session, évincer l’état ou juger la nouvelle requête hors périmètre. Le journal du serveur sait ce qu’il a demandé. Il ne sait pas quelle décision l’agent utilisateur a prise.

Le RFC 10025, norme IETF publiée en juillet 2026 et remplaçant le RFC 6265, rend cette séparation explicite. Set-Cookie transmet un couple nom-valeur et des métadonnées. Plus tard, Cookie transporte les couples sélectionnés. Les attributs, la politique et l’histoire de stockage ne reviennent pas au serveur sous forme d’accusé de réception.

Deux profils qui ne promettent pas la même chose

Le producteur devrait se limiter au profil bien formé de la section consacrée aux serveurs. Le consommateur doit appliquer l’algorithme plus libéral prévu pour la diversité des émissions existantes. Cette asymétrie améliore l’interopérabilité ; elle n’atteste pas que les deux extrémités ont construit le même objet.

Une validation côté serveur peut donc conclure « instruction conforme ». Elle ne connaît ni le moteur consommateur, ni sa version de politique, ni le contexte de la réponse. L’algorithme de stockage commence même par permettre à l’agent utilisateur d’ignorer entièrement le cookie reçu. Le mot « reçu » ne signifie pas « admis ».

La responsabilité est distribuée. L’application choisit le champ. La pile HTTP le transporte. L’agent utilisateur interprète et conserve. L’utilisateur ou l’administrateur peut restreindre la politique. Une navigation, un document imbriqué, un worker ou une API non HTTP produit ensuite un nouveau contexte. Enfin, le service décide si la chaîne reçue correspond à une session et à une action permise.

L’admission fabrique un état local

Le consommateur rejette certaines valeurs de contrôle, les couples trop longs, les portées de domaine impossibles et des combinaisons d’attributs interdites. SameSite=None exige Secure. Les noms préfixés par __Secure- ou __Host- ne sont admis que si leurs garanties associées sont satisfaites. Le contrôle du préfixe côté agent utilisateur est insensible à la casse précisément parce que certains serveurs traitent mal cette différence.

Après admission, l’état comprend le nom, la valeur, l’échéance effective, le domaine, le chemin, les dates de création et de dernier accès ainsi que les indicateurs de persistance, d’hôte seul, de canal sûr, de protection HttpOnly et de contexte SameSite. Max-Age l’emporte sur Expires. L’absence de Domain produit une portée d’hôte. Une nouvelle entrée ne remplace l’ancienne que si nom, domaine et chemin coïncident.

Le texte émis n’est donc pas l’état stocké. Une mesure sérieuse doit conserver l’empreinte de l’instruction et celle de son interprétation, puis nommer la règle qui a refusé ou transformé l’entrée. Sans cela, une erreur de syntaxe, une politique de confidentialité et un remplacement légitime deviennent le même événement : « cookie absent ».

Une échéance n’achète pas la conservation

Le serveur annonce une durée maximale ; il ne réserve aucune place. L’agent utilisateur peut ajuster l’échéance, appliquer une limite d’âge, supprimer les éléments expirés, évincer les éléments excédentaires et effacer les cookies non persistants lorsque prend fin la session telle qu’il la définit. Une suppression par l’utilisateur ou une règle de protection peut intervenir plus tôt.

Dire « valable trente jours » décrit donc l’intention du producteur, pas une preuve de garde pendant trente jours. L’événement utile est plus précis : expiration effective, remplacement, suppression explicite, fin de session, pression de quota ou purge de politique. Dans un environnement administré, ce motif peut rester localement auditable. Sur le Web public, il faut préférer des catégories agrégées ou un diagnostic consenti : l’observabilité ne justifie ni l’exfiltration du secret ni l’inventaire de la navigation.

Chaque requête rouvre la décision

Une entrée présente dans le magasin n’est sélectionnée qu’après examen de l’URI, de l’état même site ou intersite et du type de récupération. L’expiration, l’hôte ou le domaine, le chemin, le canal sûr, HttpOnly et SameSite peuvent tous l’écarter. La politique de l’agent utilisateur peut aussi omettre entièrement le champ Cookie.

Le standard Fetch intègre les cookies aux identifiants du processus de requête. L’accès document.cookie défini par HTML est une surface non HTTP et ne voit pas les entrées HttpOnly. Les documents ancêtres, les workers et les navigations ne produisent pas tous le même « site pour les cookies ». Enregistrer seulement l’URL finale ne suffit donc pas à reproduire la sélection.

SameSite est un bon test de modestie. Strict, Lax, None et Default ne sont pas des étiquettes universelles de confiance. Leur effet dépend du contexte, et un mode de compatibilité peut autoriser brièvement une requête de navigation que le nom « Lax » laisserait mal deviner. Le RFC présente SameSite comme une défense en profondeur contre certaines attaques, non comme une solution générale. Il souligne aussi que ce choix appartient au serveur, pas à l’utilisateur.

Le retour perd l’explication

Le champ Cookie renvoie des couples nom-valeur. Il ne renvoie ni Domain, ni Path, ni date de création, ni motif de sélection. Plusieurs entrées portant le même nom peuvent coexister avec des domaines ou chemins différents. Le serveur ne devrait pas déduire une priorité métier de leur ordre.

Avec HTTP/2 et HTTP/3, une chaîne de cookies unique peut en outre être transportée dans plusieurs lignes de champ. Cette représentation ne recrée pas l’histoire du magasin. L’application doit encore parser la chaîne, choisir une session, vérifier sa révocation, authentifier le principal et autoriser la méthode sur la ressource selon la sémantique HTTP et sa propre politique.

La présence d’un identifiant n’est pas la volonté de l’utilisateur. Le RFC décrit le cookie comme une autorité ambiante : l’agent utilisateur peut joindre un secret à une requête déclenchée par un tiers qui ne connaît pas ce secret. Le serveur ne peut donc pas remplacer la provenance de la requête, une protection anti-CSRF et l’autorisation de la ressource par le seul test « cookie présent ».

Six verdicts, aucun secret dans le journal

Un reçu exploitable commence par l’émission : URL de réponse, heure, lignes Set-Cookie ordonnées et non combinées, version du déploiement, empreinte masquant la valeur. L’admission ajoute le moteur consommateur, la version de politique, l’issue du parseur et la classe de refus. Le stockage décrit la portée normalisée, les indicateurs, l’échéance effective et le remplacement éventuel.

La conservation ajoute l’expiration, la suppression, la fin de session ou l’éviction quand ce fait est observable. La récupération lie une requête à son URI, sa méthode, son initiateur, son contexte de premier niveau, son calcul SameSite et les identifiants opaques inclus ou retenus. Enfin, l’application consigne séparément le parsing, la recherche de session, l’authentification, l’autorisation et le résultat.

Ce reçu est une proposition de gouvernance de Daniel Kade, pas une exigence du RFC 10025. Il ne doit contenir aucune valeur de cookie, jeton porteur ou secret de session. Son intérêt est de rendre vraies des affirmations plus petites : « le serveur a émis », « ce client administré a admis », « cette requête a sélectionné », « ce service a autorisé ».

Cette méthode rejoint l’idée de Heng Lu selon laquelle le code en fonctionnement reste la preuve première. Le miroir des politiques montre qui a décidé à chaque étape ; il ne prête pas au serveur la décision du navigateur. C’est aussi la discipline d’un média qui prend la réalité, et non le plaidoyer, pour produit.

Sources