17. Set-Cookie, portée et préfixes

Comprendre le mécanisme

Secure limite l’envoi du cookie aux contextes de transport prévus comme sûrs ; HttpOnly réduit sa lecture directe via les API JavaScript concernées. SameSite contrôle certains contextes intersites. Ces attributs sont complémentaires, sans assurer l’autorisation métier ni éliminer toutes les conséquences d’une XSS. Domain et Path règlent la portée d’envoi ; un chemin ne doit pas être présenté comme une séparation de confiance absolue entre applications.

Raisonner et vérifier

Le préfixe __Host- impose des conditions utiles sur un cookie accepté par un navigateur conforme : Secure, Path=/ et absence de Domain. Pour supprimer un cookie, faites correspondre sa portée à celle de la valeur créée. Examinez les cookies dupliqués plutôt que conclure à une déconnexion à partir d’un seul champ. Testez les attributs effectivement vus dans le navigateur derrière le proxy HTTPS.

Secure

Secure restreint l’envoi du cookie aux canaux prévus comme sécurisés. La lecture du script relève notamment de HttpOnly. Le navigateur limite l’envoi selon les conditions sécurisées de cet attribut. Vérifiez HTTPS sur le parcours exposé et la perception du schéma derrière les proxies ; un attribut seul ne remplace pas toute la politique de transport.

HttpOnly

HttpOnly limite l’accès direct par JavaScript. Le script peut encore agir dans le contexte compromis. Le script ne peut pas lire directement le cookie par les API ordinaires concernées. Une XSS peut néanmoins déclencher des actions dans la page ; gardez encodage de sortie et prévention d’injection.

SameSite

SameSite concerne des conditions d’envoi inter-sites. Il ne chiffre pas la valeur. Cette politique porte sur des conditions d’envoi inter-sites. Site et origine diffèrent ; testez vos sous-domaines et parcours de navigation au lieu d’assimiler SameSite à un contrôle universel d’origine.

None avec Secure

SameSite=None demande Secure dans les navigateurs concernés. Les navigateurs imposent des contraintes à ce mode. Les navigateurs concernés exigent Secure pour SameSite=None. Observez l’acceptation réelle et les avertissements ; une ligne Set-Cookie présente dans la réponse peut être rejetée par le client.

Préfixe __Host-

__Host- exige notamment Secure, Path=/ et absence de Domain. Le préfixe réduit le périmètre selon des règles précises. Le préfixe exige notamment Secure, Path=/ et aucune directive Domain. Cette forme limite certaines portées, mais ne constitue pas à elle seule une authentification ou une politique complète de session.

Path

Path ne remplace pas une frontière d’autorisation métier. Le périmètre d’envoi n’établit pas le rôle. Un chemin d’envoi réduit où le navigateur joint le cookie. Il ne prouve pas qu’un acteur est autorisé sur une ressource de ce chemin et ne remplace pas les contrôles applicatifs.

Construction

Set-Cookie doit suivre les API de construction adaptées. Les valeurs non contrôlées peuvent altérer le champ. Utilisez les API de cookie pour encoder valeur et attributs correctement. Une concaténation de données non fiables dans une ligne brute peut créer un résultat ambigu ou être refusée par les composants.

Deux expirations

L’expiration du cookie ne définit pas seule l’expiration serveur. Le backend doit gérer son propre cycle de session. Max-Age ou Expires guide la conservation navigateur. Le serveur doit encore limiter l’acceptation de la session ; un client peut conserver une ancienne valeur et la présenter explicitement.

Périmètre minimal

Un cookie sensible doit avoir un périmètre minimal. Un périmètre élargi peut exposer plus de contextes. Évitez Domain trop large et valeurs inutiles dans le cookie. La portée doit correspondre aux composants qui ont réellement besoin de recevoir cette capacité, avec conservation et retrait définis.

Observation déployée

Les attributs doivent être observés dans la réponse déployée. Proxy et déploiement peuvent influencer la réponse. Inspectez la réponse et le stockage navigateur après passage par le proxy. Une configuration locale correcte peut être transformée ou rejetée sur le trajet effectif ; testez le résultat reçu.

Atelier guidé : lire, expliquer et vérifier le code

Set-Cookie: __Host-lab=abc; Secure; Path=/; Domain=example.test; HttpOnly

Le cookie commence par __Host- mais contient Domain=example.test, en contradiction avec les exigences du préfixe. Identifiez cette directive puis vérifiez le stockage dans un navigateur. La présence textuelle du header ne garantit pas que le client accepte effectivement le cookie.

Ce préfixe exige notamment l’absence de Domain. Secure fait partie des conditions attendues. La racine est le chemin attendu pour ce préfixe. HttpOnly ne contredit pas ce contrat.

Travail pratique : Vérifiez les attributs d’un cookie de laboratoire derrière un proxy et testez sa suppression avec le bon chemin.

Critères de correction : Comparez le Set-Cookie reçu et le magasin navigateur. Vérifiez le transport HTTPS reconnu par l’application, puis la disparition effective de la valeur visée et l’invalidation serveur. Ne vous contentez pas d’un message visuel de déconnexion.