L'entête de réponse HTTP Set-Cookie
est utilisé pour envoyer un cookie depuis le serveur à l'agent utilisateur pour qu'il puisse le renvoyer dans l'avenir.
Pour plus d'information, voir le guide sur les cookies HTTP.
Type de l'entête | Response header |
---|---|
Forbidden header name | no |
Syntaxe
Set-Cookie: <cookie-name>=<cookie-value> Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date> Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit> Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value> Set-Cookie: <cookie-name>=<cookie-value>; Secure Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None // Plusieurs directives sont aussi pussibles, par exemple: Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
Attributs
<cookie-name>=<cookie-value>
- Un cookie commence avec la paire nom-valeur:
- Un
<cookie-name>
peut-être de n'importe que caractères US-ASCII, à part les caractères de contrôle, d'espace, de tabulation et les caractères de séparation:( ) < > @ , ; : \ " / [ ] ? = { }
. - Un
<cookie-value>
peut éventuellement être entouré de doubles guillemets et inclut tout les caractères US-ASCII sauf les caractères de contrôle, Whitespace, doubles guillemets, virgule, point-virgule et antislash. Encodage: plusieurs implémentations font un codage d'URL, cependant ce n'est pas obligatoire par la spécification RCF même si cela peut aider pour avoir des caractères permis. __Secure-
préfixe : Les cookies commençant par__Secure-
(le tiret fait partit du préfixe) doivent être définit avec le drapeausecure
depuis une page sécurisée (HTTPS).__Host-
préfixe : Les cookies commençant par__Host-
doivent être définit avec le drapeausecure
, depuis une page sécurisée (HTTPS), ne doivent pas avoir de domaine spécifié (et donc pas envoyé à un sous-domaine) et le chemin doit être/
.
- Un
Expires=<date>
Facultatif-
Le temps de vie maximal d'un cookie sous la forme d'une Date HTTP. Voir
Date
pour le format requis.Si non spécifié, le cookie devient un cookie de session. Une session finit quand le client s'arrête et les cookies de sessions seront supprimés.
Attention: Plusieurs navigateurs ont un système de récupération de session qui enregistre les onglets et les restaure quand le navigateur redémarre. Les cookies de session seront aussi restaurés comme si le navigateur ne s'était jamais arrêté.
Quand la date expire, la date limite est relative au client qui le supprime, pas le serveur.
Max-Age=<number>
Facultatif- Le nombre de secondes avant son expiration. Une valeur nulle ou négative fera expirer immédiatement le cookie. Si il y a
Expires
etMax-Age
configuré,Max-Age
sera prioritaire. Domain=<domain-value>
Facultatif- Le domaine où le cookie sera envoyé.
- Si omis, la valeur par défaut sera l'hôte de l'URL du document courant. Les sous domaines ne seront pas inclus.
- Contrairement aux anciennes spécifications, le point au début dans les noms de domaines (
.example.com
) est ignoré. - Plusieurs valeurs de domaine ne sont pas permis. Si un nom de domaine est spécifié, les sous domaines sont toujours inclus.
Path=<path-value>
Facultatif- Un chemin doit exister dans l'URL de requête, ou le navigateur ne va pas envoyer d'entête
Cookie
. - La barre oblique (
/
) est interprétée comme un séparateur de répertoire. Les sous répertoires sont inclus, par exemple: pourPath=/docs
les répertoires/docs
,/docs/Web/
et/docs/Web/HTTP
sont concernés. Secure
Facultatif- Un cookie sécurisé est envoyé uniquement si la requête est fait en
https:
. Cependant des informations confidentielles ne devraient jamais être enregistrées dans un cookie classique, en effet le mécanique est non sécurisé et ne chiffre aucune information.Note: Les sites non sécurisés (
http:
) ne peuvent plus définir des cookie «Secure» désormais (depuis Chrome 52+ et Firefox 52+). HttpOnly
Facultatif- Empêche JavaScript d'accéder au cookie; par exemple, au travers de la propriété
Document.cookie
, de l'APIXMLHttpRequest
ou de l'APIRequest
. Cela protège des attaques cross-site scripting (XSS). SameSite=<samesite-value>
Facultatif-
Strict
: Le navigateur envoie le cookie uniquement pour les requêtes sur le même site (c'est à dire, les requêtes où le cookie a été défini). Si la requête vient d'une autre URL que celle courante, aucun cookie avec d'attributSameSite=Strict
n'est envoyé.Lax
: Le cookie n'est pas envoyé pour des requêtes croos-site, comme le chargement d'image ou de cadre, mais est envoyé quand un utilisateur va sur une autre site, comme lorsqu’il suit un lien.None
: Le navigateur envoie le cookie à la fois pour les requêtes cross-site et same-site.
S'assurer qu'un cookie ne peut pas être envoyé avec des requêtes cross-origin empêche une partie des attaques Cross-Site Request Forgery (CSRF).
Les navigateurs sont en migration pour que par défaut
(en) SameSite=Lax
. Si un cookie est doit être envoyé en cross-site, définissez explicitement la valeur None. Cette valeur nécessite l’attribut Secure.
Exemples
Cookie de session
Les cookies de session sont supprimés quand le client s'éteint. Les cookies sont des cookies de session s'ils n'ont pas de directive Expires
ou Max-Age.
Set-Cookie: sessionId=38afes7a8
Cookie permanent
Au lien d'expirer quand le client s'éteint, le cookies permanent expirent à une date spécifique (Expires
) ou après une valeur de temps (Max-Age
).
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
Set-Cookie: id=a3fWa; Max-Age=2592000
Domaines invalides
Un cookie pour un domaine qui n'inclut pas le serveur qui le défini doit être (en) rejeté par l'agent utilisateur.
Le cookie suivant sera rejeté si le serveur est hébergé sur originalcompany.com
:
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
Un cookie pour un sous-domaine du domaine servi sera rejeté.
Le cookie suivant sera rejeté si le serveur est hébergé sur example.com
:
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
Préfixes de cookie
Les cookies préfixés par __Secure-
ou __Host-
peuvent être utilisés seulement s'ils sont définits avec l'attribut secure
depuis une origine sécurisée (HTTPS).
De plus, les cookies avec le préfixe __Host-
doivent avoir doivent avoir un path
valant /
(donc tout les chemins de l'hôte) et ne doit pas avoir d'attribut Domain
.
Pour les clients qui n'implémentent pas les préfixes aux cookies, vous ne pouvez pas compter sur ses assurances, les cookies avec un préfixe seront toujours acceptés.
// Les deux sont acceptés s'ils viennent d'une origine sécurisée (HTTPS) Set-Cookie: __Secure-ID=123; Secure; Domain=example.com Set-Cookie: __Host-ID=123; Secure; Path=/ // Rejeté car l'attribut Secure est manquant Set-Cookie: __Secure-id=1 // Rejeté car l'attribut Path=/ est manquant Set-Cookie: __Host-id=1; Secure // Rejeté à cause du domaine qui est spécifié Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
Spécifications
Spécification | Titre |
---|---|
RFC 6265, section 4.1: Set-Cookie | HTTP State Management Mechanism |
draft-ietf-httpbis-rfc6265bis-05 | Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies |
Compatibilité des navigateurs
BCD tables only load in the browser
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
Note de compatibilité
- À partir de Chrome 52 et Firefox 52, les sites non sécurisés (
http:
) ne peuvent plus définir des cookies avec la directiveSecure
.