Résumé

  • Un cookie RFC 10025 est une donnée d’état que l’agent utilisateur peut conserver puis retourner selon des règles de sélection. Sa signification métier et l’acceptation d’une session restent du côté du service.
  • Les attributs Domain, chemin, Secure, HttpOnly, SameSite et les préfixes réduisent des classes précises d’émission ou de retour. Ils ne rendent pas une demande intentionnelle, autorisée ou exécutée.
  • Une enquête utile relie émission et révocation de session, contexte de requête, décision d’autorisation, prévention du rejeu, écriture effective et résultat extérieur sans laisser une seule ligne d’en-tête parler à leur place.

Une équipe de support reçoit une contestation : l’adresse de récupération d’un compte a changé alors que son titulaire affirme ne l’avoir jamais demandé. Les journaux disent que l’opération est venue d’une session connue. L’application a donc une trace de corrélation, pas encore un récit complet. Elle sait quel état le navigateur a présenté et quelle session le serveur a choisie. Elle ne sait pas, par cette seule preuve, comment l’instruction a été construite, si une autre page a provoqué l’envoi, si la session devait encore avoir ce privilège, ni si la modification a atteint tous les systèmes dépendants.

Cette différence est la frontière entre une infrastructure de preuve et une formule magique.

RFC 10025 normalise les champs Set-Cookie et Cookie et le comportement de stockage et de récupération qui les entoure. Il ne normalise pas le sens applicatif de la valeur. Une chaîne opaque peut référer à une session côté serveur, porter un état protégé, sélectionner un panier ou servir une préférence. Le protocole ne décide pas ce que cette chaîne représente. L’application ne peut donc pas raisonnablement tirer de sa présence une conclusion que son propre modèle n’a pas établie.

Les limites exactes du périmètre navigateur

Le navigateur reçoit des attributs de domaine, de chemin, d’expiration, de transport sécurisé, d’accès HTTP et de même site. Il peut aussi ignorer un cookie ou l’évincer selon ses règles. Cette dernière possibilité paraît secondaire jusqu’au jour où une politique de session suppose qu’un navigateur est une base de données fiable. Il ne l’est pas. Le serveur doit rester l’autorité de l’acceptation courante.

Un cookie sans Domain est attaché à son hôte ; un Domain valable élargit la sélection aux hôtes correspondants. Le traitement des suffixes publics limite certaines affectations trop hautes. Cela protège une frontière de distribution, non une chaîne de confiance complète entre tous les services qui pourraient partager un suffixe. La question opérationnelle n’est pas « le navigateur peut-il l’envoyer ici ? », mais « ce service-ci peut-il employer cette session-ci pour cette opération-ci ? »

La même prudence vaut pour le chemin. Il aide à sélectionner, mais n’isole ni lecture ni autorité. Le serveur doit définir comment il interprète des noms semblables, des valeurs concurrentes et des routes inattendues. Une règle de navigateur ne remplace pas la grammaire d’acceptation d’un service.

Secure limite le retour aux connexions que l’agent utilisateur tient pour sûres. HttpOnly restreint certaines interfaces non HTTP. Les deux sont de bonnes décisions de périmètre. Aucun ne dit que la personne attendue tient le clavier, que le jeton n’a pas été invalidé, ou que le contenu d’une requête mérite une exécution. Surtout, HttpOnly n’empêche pas le navigateur d’ajouter le cookie à une requête HTTP applicable. L’autorité peut donc rester ambiante même si la valeur n’est pas lisible par un script.

RFC 10025 emploie ce terme d’autorité ambiante avec raison. Un navigateur peut remettre une donnée assimilable à un justificatif à une ressource que quelqu’un d’autre lui a fait viser. La protection ne consiste pas à nier ce comportement ; elle consiste à demander séparément si la demande et son action sont recevables.

Le même site n’est pas une signature de volonté

SameSite est un contrôle utile parce qu’il réduit certaines occasions de retour intersite. Mais le RFC le présente comme une défense en profondeur face à certaines attaques CSRF, et non comme une défense générale, robuste et autonome. Son comportement par défaut comporte de surcroît des compromis de compatibilité pour un cookie récent.

Le choix d’architecture ne devrait jamais être « SameSite ou protection de la demande ». Il devrait être : quelles vérifications l’action exige-t-elle en plus de la session ? Pour une modification d’adresse, une exportation ou une instruction financière, un service peut devoir contrôler le contexte, lier un anti-forgery token à la session et à la route, demander une authentification récente, imposer une seconde approbation ou différer l’exécution. Ce sont des décisions de produit et de risque. Les mettre sous le nom d’un attribut de cookie les rend invisibles.

Les préfixes rendent la séparation encore plus nette. __Secure- impose une origine sécurisée et l’attribut Secure. __Host- impose en plus Path=/ et l’absence de Domain. Ces conditions rendent une mauvaise émission plus difficile. Elles ne consultent pas le registre de révocation d’une session, ne lisent pas un plafond de transaction et ne rapprochent pas un résultat aval. Elles sont solides précisément parce qu’elles ne prétendent pas faire ce travail différent.

Après la reconnaissance de session, le travail commence

Le serveur peut reconnaître un identifiant et néanmoins refuser la session. Elle peut avoir expiré, avoir été renouvelée après un changement de mot de passe, être liée à un état de récupération, être exclue par une règle de risque ou avoir perdu le droit d’exécuter une opération privilégiée. Le navigateur ne sait pas ces choses et n’a pas à les savoir.

La fixation de session révèle bien l’enjeu. Le problème n’est pas qu’un cookie existe avant l’authentification ; il apparaît si l’application laisse le même identifiant traverser un changement d’autorité sans rotation et sans décision nouvelle. La réparation est observable : événement d’émission, rotation, invalidation de l’ancien identifiant, et refus ultérieur si cet identifiant revient. Lire a posteriori la valeur du cookie ne produit aucune de ces preuves.

L’autorisation doit ensuite regarder l’action, non seulement le compte. Une session qui permet de consulter un tableau de bord n’est pas une autorisation illimitée de modifier un bénéficiaire, de publier une clé ou d’effacer une archive. Rôle actif, objet ciblé, limites, mandat, délai de refroidissement et contrôle à deux personnes peuvent tous compter. Ces objets appartiennent au domaine métier ; un en-tête HTTP ne les crée pas.

Enfin, accepter une commande et produire un effet sont des événements distincts. Une réponse réussie peut signifier qu’un travail a été placé en file, qu’une écriture locale a été validée, ou qu’une intégration externe a commencé. La réconciliation doit indiquer ce qui a réellement suivi. Sinon, lors d’un litige, l’organisation confond une intention reçue, une décision serveur et une conséquence.

Une chaîne qui reste lisible sous pression

À l’émission, conservez une référence de session, son sujet, l’événement qui l’a créée, ses attributs de portée, sa durée et ses conditions de révocation. À la réception, conservez l’hôte, la route, la session effectivement sélectionnée, le résultat de contrôle de contexte et la raison d’un refus. À la décision, reliez l’action demandée à la règle, au rôle, à la preuve supplémentaire éventuelle et à l’horodatage. À l’effet, conservez une référence de tentative, le statut de validation, la référence aval et l’observation finale.

Cette séquence ne veut pas dire tout journaliser ou soumettre toute page à une cérémonie lourde. Elle dit qu’une assertion doit rester à sa couche. Un cookie correspond à une sélection de navigateur. Une session acceptée correspond à une décision de service. Une opération autorisée et un résultat observé exigent leurs propres preuves.

Sources