Attributs de cookie : Secure, HttpOnly, SameSite, Domain, Path et le préfixe __Host-

Ce que c'est

Un en-tête Set-Cookie porte un nom, une valeur et des attributs. La RFC 6265 et son brouillon successeur (rfc6265bis, qui ajoute SameSite et les préfixes) les définissent :

• Domain : omis, le cookie ne retourne qu'à l'hôte d'origine (limité à l'hôte). Défini à example.com, il est envoyé à cet hôte et à chaque sous-domaine. Une valeur qui ne couvre pas l'origine est rejetée, et la RFC 6265 note que de nombreux agents utilisateurs rejettent aussi les suffixes publics tels que co.uk.
• Path : prend par défaut le répertoire du chemin de la requête ; la correspondance se fait par préfixe. La RFC 6265 dit que cela « ne peut pas être considéré comme fiable pour la sécurité ».
• Secure : envoyé uniquement sur des canaux sécurisés. La RFC 6265 avertit que cela protège la confidentialité, pas l'intégrité ; le brouillon ajoute que les origines non sécurisées ne peuvent pas écraser un cookie sécurisé existant.
• HttpOnly : omis des API non HTTP telles que document.cookie, mais toujours envoyé avec fetch et XMLHttpRequest.
• SameSite : Strict n'envoie que sur des requêtes du même site ; Lax aussi sur des navigations de premier niveau intersites avec des méthodes sûres ; None envoie partout et est rejeté sauf si Secure est également défini. MDN note que certains navigateurs traitent un attribut absent comme Lax.
• Max-Age et Expires : Max-Age l'emporte lorsque les deux sont présents ; ni l'un ni l'autre ne fait un cookie de session.
• Préfixes : un nom commençant par __Secure- n'est accepté qu'avec Secure ; __Host- exige en outre Path=/ et l'absence de Domain, de sorte que le cookie soit verrouillé sur un seul hôte. Le brouillon indique que les ports sont le seul élément du modèle d'origine que les cookies __Host- continuent d'ignorer.

Pourquoi c'est important

Les cookies ne sont pas liés aux origines. La RFC 6265 indique qu'ils n'offrent d'isolation ni par port ni par schéma ; un sous-domaine peut définir un cookie pour son domaine parent et masquer celui du parent. L'en-tête de requête Cookie ne porte aucun attribut, si bien que le serveur ne peut pas savoir comment un cookie a été défini ; les préfixes existent pour lui donner cette certitude.

Comment l'appliquer

• Cookie de session : __Host-session=<id>; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=<seconds>.
• Omettre Domain sauf si des sous-domaines doivent partager le cookie, et accepter alors que chaque sous-domaine puisse l'écraser.
• SameSite=Strict pour les cookies utilisés uniquement à l'intérieur de l'application ; Lax pour les connexions qui doivent survivre à une arrivée via un lien externe ; None seulement pour un usage intersites intégré, toujours avec Secure.
• Ne pas séparer deux applications sur un même hôte par Path ; leur donner des hôtes distincts.
• Supprimer en redéfinissant avec le même nom, le même Domain et le même Path, et Max-Age=0.

Pièges

Un point de tête dans Domain est ignoré, un point final fait ignorer l'attribut. La RFC 6265 dit que les agents utilisateurs à usage général devraient prendre en charge au moins 4096 octets par cookie et 50 cookies par domaine ; au-delà de telles limites, des cookies peuvent être abandonnés silencieusement. Deux services sur des ports différents d'un même hôte voient les cookies l'un de l'autre.