Set-Cookie
Utilisation
L’en-tête Set-Cookie demande au client de stocker une paire nom-valeur accompagnée d’attributs facultatifs qui contrôlent la portée, la durée de vie et les propriétés de sécurité du cookie. Chaque en-tête Set-Cookie définit exactement un cookie. Les serveurs qui envoient plusieurs cookies incluent plusieurs en-têtes Set-Cookie dans la même réponse.
La syntaxe générale consiste en un nom et une valeur de cookie séparés par un signe égal, suivis d’attributs facultatifs délimités par des points-virgules.
Set-Cookie: <name>=<value>; <attributes>Le nom du cookie accepte les caractères US-ASCII à l’exception des caractères de contrôle, des espaces, des tabulations et des caractères séparateurs ( ) < > @ , ; : \ ” / [ ] ? = { }. La valeur du cookie accepte les caractères US-ASCII à l’exclusion des caractères de contrôle, des espaces, des guillemets doubles, des virgules, des points-virgules et des barres obliques inverses. Les valeurs peuvent facultativement être encadrées par des guillemets doubles.
Les navigateurs empêchent le JavaScript frontal de lire l’en-tête Set-Cookie via la Fetch API et XMLHttpRequest. Cet en-tête est un nom d’en-tête de réponse interdit dans la spécification Fetch. Les cookies présents dans les réponses CORS sont ignorés, sauf si la requête inclut des identifiants.
Préfixes de cookie
Les préfixes de nom de cookie imposent des contraintes supplémentaires appliquées par le navigateur, offrant des garanties sur l’endroit et la manière dont un cookie a été défini.
Le préfixe __Secure- exige l’attribut Secure et une origine HTTPS. Cela empêche les sites servis uniquement en HTTP de définir des cookies portant le même nom qu’un cookie sécurisé.
Set-Cookie: __Secure-ID=abc; Secure; Path=/Le préfixe __Host- ajoute des exigences plus strictes : l’attribut Secure, aucun attribut Domain, et Path défini à /. Cela lie le cookie au nom d’hôte exact de l’origine, empêchant toute interférence des sous-domaines.
Set-Cookie: __Host-ID=abc; Secure; Path=/Le préfixe __Http- exige à la fois les attributs Secure et HttpOnly et ne peut être défini que via l’en-tête Set-Cookie, jamais via JavaScript.
Set-Cookie: __Http-ID=abc; Secure; HttpOnlyLe préfixe __Host-Http- combine les restrictions de __Host- et de __Http-, créant la liaison de cookie la plus restrictive disponible.
Set-Cookie: __Host-Http-ID=abc; Secure; HttpOnly; Path=/Remarque
Les préfixes __Http- et __Host-Http- proviennent d’une proposition de préfixes de cookie distincte, différente des préfixes établis __Secure- et __Host- que les navigateurs appliquent largement. Ces préfixes plus récents en restent au stade de proposition.
Impact SEO
Googlebot envoie les cookies lorsque l’origine les définit, mais ne conserve pas les cookies d’une session d’exploration à l’autre. Des cookies volumineux sur les domaines de ressources augmentent la taille des requêtes pendant le rendu. Un domaine sans cookie pour les ressources statiques évite cette surcharge. Évitez de conditionner l’accès au contenu à une logique dépendante des cookies qui empêche les robots d’explorer la page.
Expires
L’attribut Expires définit une date d’expiration absolue au format HTTP-date. Passé cette date, le client n’envoie plus le cookie. Lorsqu’il est omis en même temps que Max-Age, le cookie devient un cookie de session supprimé à la fermeture du client. Les navigateurs corrigent le décalage d’horloge à l’aide de l’en-tête Date de la réponse.
Expires=Thu, 31 Dec 2026 23:59:59 GMTRemarque
Les navigateurs plafonnent la valeur Expires à 400 jours à compter du moment où le cookie est défini. Cette limite permet aux sites visités environ une fois par an de conserver leurs cookies tout en empêchant une persistance indéfinie.
Max-Age
L’attribut Max-Age définit la durée de vie du cookie en secondes à partir du moment où le client reçoit la réponse. Une valeur nulle ou négative fait expirer le cookie immédiatement. Lorsque Expires et Max-Age sont tous deux présents, Max-Age l’emporte.
Max-Age=2592000La Cookie Store API en JavaScript expose également une option maxAge via la méthode cookieStore.set(), reflétant cet attribut pour une gestion programmatique des cookies. L’API n’autorise pas de définir à la fois expires et maxAge sur le même cookie.
Remarque
Les navigateurs plafonnent la valeur Max-Age à 400 jours (34 560 000 secondes), ce qui correspond au plafond d’Expires.
Domain
L’attribut Domain indique quels hôtes reçoivent le cookie. Lorsqu’il est défini, le cookie est disponible pour le domaine spécifié et tous ses sous-domaines. Lorsqu’il est omis, le cookie est par défaut limité à l’hôte d’origine exact, sous-domaines exclus (un cookie restreint à l’hôte). Seul le domaine courant ou un domaine parent de l’hôte courant est valide. Les points initiaux sont ignorés.
Domain=example.rePath
L’attribut Path limite la transmission du cookie aux requêtes correspondant au préfixe de chemin d’URL spécifié. La barre oblique / délimite les segments de chemin. Un cookie avec Path=/docs correspond à /docs, /docs/, /docs/Web/HTTP mais pas à / ni à /docsets.
Path=/Remarque
L’attribut Path n’est pas un mécanisme de sécurité. Tout script de la même origine a accès à l’ensemble des cookies, quelles que soient les restrictions de chemin.
Secure
L’attribut Secure restreint le cookie aux connexions HTTPS. Le navigateur n’envoie jamais un cookie sécurisé sur du HTTP non chiffré. Les origines non sécurisées ne peuvent pas définir de cookies portant cet attribut. Localhost est dispensé de l’exigence HTTPS pendant le développement.
HttpOnly
L’attribut HttpOnly bloque l’accès JavaScript au cookie via document.cookie, la Cookie Store API et les autres interfaces DOM. Le cookie reste envoyé avec les requêtes HTTP initiées par JavaScript via fetch() et XMLHttpRequest. Cet attribut atténue les attaques de type cross-site scripting (XSS) qui cherchent à dérober les valeurs des cookies.
SameSite
L’attribut SameSite détermine si le navigateur envoie le cookie avec les requêtes intersites. Trois valeurs sont définies.
Strict n’envoie le cookie qu’avec les requêtes du même site. Les navigations intersites, y compris le clic sur un lien depuis un site externe, n’incluent pas le cookie.
Lax envoie le cookie avec les requêtes du même site et les navigations intersites de premier niveau où la barre d’adresse change. Les requêtes de sous-ressources, les appels fetch() et les navigations dans les iframes n’incluent pas le cookie. La plupart des navigateurs utilisent Lax par défaut lorsqu’aucun attribut SameSite n’est spécifié.
None envoie le cookie avec toutes les requêtes, y compris les requêtes intersites. L’attribut Secure est obligatoire avec SameSite=None. Les cookies provenant d’un schéma différent (HTTP vs HTTPS) sont traités comme intersites.
SameSite=LaxPartitioned
L’attribut Partitioned stocke le cookie dans un espace de stockage partitionné dont la clé combine l’origine du cookie et le site de premier niveau. Un cookie partitionné défini par cdn.example.re intégré sur shop.example.org n’est envoyé que lorsque cdn.example.re est intégré sur shop.example.org, et non lorsqu’il est intégré sur d’autres sites.
Cet attribut fait partie de la proposition Cookies Having Independent Partitioned State (CHIPS). Il permet des cas d’usage intersites légitimes comme les widgets intégrés, la répartition de charge CDN et les fournisseurs de CMS headless, sans accorder de capacité complète de suivi intersite.
L’attribut Secure est obligatoire. Le préfixe __Host- est recommandé pour lier le cookie à l’origine exacte.
Set-Cookie: __Host-sess=abc; SameSite=None; Secure; Path=/; PartitionedPris en charge par les navigateurs basés sur Chromium et par Firefox. Safari partitionne les cookies tiers par défaut via un mécanisme distinct et n’utilise pas cet attribut.
Exemple
Un cookie de session sans attribut d’expiration. Le cookie est supprimé à la fin de la session du client.
Set-Cookie: sessionId=38afes7a8Un cookie persistant d’une durée de vie de 30 jours. L’attribut Max-Age définit l’expiration relativement à l’heure courante.
Set-Cookie: id=a3fWa; Max-Age=2592000Un cookie doté d’attributs de sécurité adaptés aux jetons d’authentification. L’attribut HttpOnly bloque l’accès JavaScript, Secure le restreint à HTTPS et SameSite=Strict empêche la transmission intersite.
Set-Cookie: __Host-token=eyJhbGci; Secure; HttpOnly; SameSite=Strict; Path=/Un cookie tiers partitionné destiné à une intégration intersite. L’attribut Partitioned isole le cookie au site de premier niveau précis où l’intégration apparaît.
Set-Cookie: __Host-embed=34d8g; SameSite=None; Secure; Path=/; PartitionedPlusieurs cookies définis dans une seule réponse. Chaque cookie exige son propre en-tête Set-Cookie.
Set-Cookie: theme=dark; Path=/; Max-Age=31536000
Set-Cookie: __Host-sid=x8Kp2; Secure; HttpOnly; SameSite=Lax; Path=/Dépannage
Les cookies qui ne persistent pas ou qui arrivent sur les mauvaises requêtes trouvent souvent leur origine dans des attributs mal appariés ou dans les politiques appliquées par le navigateur.
Cookie non stocké à cause de l’indicateur Secure sur HTTP. L’attribut Secure exige une connexion HTTPS. Un cookie défini avec Secure sur du HTTP simple est silencieusement rejeté. Vérifiez le protocole dans la barre d’adresse du navigateur et inspectez les en-têtes Set-Cookie dans l’onglet Network des DevTools. Localhost est dispensé de cette restriction pendant le développement.
Cookie non envoyé avec les requêtes intersites (valeur SameSite par défaut). Les navigateurs modernes utilisent SameSite=Lax par défaut lorsqu’aucun attribut SameSite n’est présent. Les sous-requêtes intersites telles que les appels fetch(), les iframes et les chargements d’images n’incluent pas le cookie. Ajoutez SameSite=None; Secure lorsque le cookie doit circuler entre sites, ou restructurez le flux pour éviter la dépendance intersite.
Non-correspondance du chemin du cookie. Un cookie défini avec Path=/app n’est pas envoyé aux requêtes visant /api ou /. Vérifiez que la valeur de Path correspond aux chemins de requête qui ont besoin du cookie. Définir Path=/ rend le cookie disponible sur l’ensemble du site.
Problèmes de portée liés à l’attribut Domain. Un cookie défini avec Domain=sub.example.re n’est pas envoyé à example.re. Omettre l’attribut Domain crée un cookie restreint à l’hôte, limité au nom d’hôte exact. Les points initiaux dans la valeur sont ignorés par les navigateurs. Utilisez le panneau Application > Cookies des DevTools pour inspecter le domaine effectif de chaque cookie stocké.
Cookie tiers bloqué par les fonctions de confidentialité du navigateur. Safari bloque les cookies tiers par défaut via Intelligent Tracking Prevention. Enhanced Tracking Protection de Firefox et Privacy Sandbox de Chrome appliquent des restrictions similaires. L’attribut Partitioned (CHIPS) offre une voie normalisée pour les cas d’usage intersites légitimes. Testez dans plusieurs navigateurs pour confirmer le comportement.
Cookie dépassant la taille maximale. Les navigateurs imposent une limite d’environ 4096 octets par cookie (nom, valeur et attributs réunis). Les cookies trop volumineux sont silencieusement abandonnés. Déplacez les charges utiles importantes vers des sessions côté serveur et ne stockez qu’un identifiant de session dans le cookie.
Déboguer les cookies stockés. Ouvrez DevTools > Application > Cookies pour inspecter tous les cookies du site courant, y compris leurs attributs, leur expiration et leur taille. L’API document.cookie n’expose pas les cookies HttpOnly. Utilisez curl -v pour voir les en-têtes Set-Cookie bruts renvoyés par le serveur.