Utiliser les cookies HTTP

À quoi servent les cookies

En général, le serveur utilise le contenu des cookies HTTP pour déterminer si différentes requêtes proviennent du même navigateur/utilisateur·ice, puis émettre une réponse personnalisée ou générique selon le cas. Ce qui suit décrit un système de connexion utilisateur·ice de base :

1. L'utilisateur·ice envoie ses identifiants de connexion au serveur, par exemple à travers un formulaire.
2. Si les identifiants sont corrects, le serveur met à jour l'interface utilisateur pour indiquer que l'utilisateur·ice est connecté·e, et répond avec un cookie contenant un identifiant de session qui enregistre son état de connexion dans le navigateur.
3. Plus tard, l'utilisateur·ice se rend sur une autre page du même site. Le navigateur envoie le cookie contenant l'identifiant de session avec la requête correspondante pour indiquer qu'il pense toujours que l'utilisateur·ice est connecté·e.
4. Le serveur vérifie l'identifiant de session et, s'il est toujours valide, envoie à l'utilisateur·ice une version personnalisée de la nouvelle page. S'il n'est pas valide, l'identifiant de session est supprimé et l'utilisateur·ice voit une version générique de la page (ou peut-être un message « accès refusé » et est invité·e à se reconnecter).

Les cookies sont principalement utilisés à trois fins :

• Gestion de session : État de connexion de l'utilisateur·ice, contenu du panier, scores de jeu ou tout autre détail lié à la session de l'utilisateur·ice que le serveur doit mémoriser.
• Personnalisation : Préférences de l'utilisateur·ice telles que la langue d'affichage et le thème de l'interface utilisateur.
• Suivi : Enregistrement et analyse du comportement de l'utilisateur·ice.

Stockage des données

Aux débuts du web, lorsqu'il n'y avait pas d'autre option, les cookies étaient utilisés à des fins générales de stockage côté client. Les API de stockage modernes sont désormais recommandées, par exemple l'API Web Storage (localStorage et sessionStorage) et IndexedDB.

Elles sont conçues pour le stockage, n'envoient jamais de données au serveur et n'ont pas les autres inconvénients liés à l'utilisation des cookies pour le stockage :

• Les navigateurs sont généralement limités à un nombre maximum de cookies par domaine (varie selon le navigateur, généralement dans les centaines), et une taille maximale par cookie (généralement 4 Ko). Les API de stockage peuvent stocker des quantités de données plus importantes.
• Les cookies sont envoyés avec chaque requête, ce qui peut nuire aux performances (par exemple sur des connexions mobiles lentes), surtout si vous avez beaucoup de cookies définis.

Créer, supprimer et mettre à jour des cookies

Après avoir reçu une requête HTTP, un serveur peut envoyer un ou plusieurs en-têtes Set-Cookie avec la réponse, chacun d'eux définissant un cookie distinct. Un cookie est défini avec une paire nom-valeur comme ceci :

Set-Cookie: <cookie-name>=<cookie-value>

La réponse HTTP suivante indique au navigateur récepteur de stocker une paire de cookies :

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: delicieux_cookie=choco
Set-Cookie: savoureux_cookie=menthe

[contenu de la page]

Lorsque qu'une nouvelle requête est effectuée, le navigateur envoie généralement les cookies précédemment stockés pour le domaine actuel au serveur dans un en-tête HTTP Cookie :

GET /page_exemple.html HTTP/2.0
Host: www.exemple.org
Cookie: delicieux_cookie=choco; savoureux_cookie=menthe

Suppression : Définir la durée de vie d'un cookie

Vous pouvez définir une date d'expiration ou une période après laquelle le cookie doit être supprimé et ne plus être envoyé. Selon les attributs définis dans l'en-tête Set-Cookie lors de la création des cookies, ils peuvent être soit des cookies permanents, soit des cookies de session :

• Les cookies permanents sont supprimés après la date définie dans l'attribut Expires :

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;
  

  ou après la période définie dans l'attribut Max-Age :

  http

  Set-Cookie: id=a3fWa; Max-Age=2592000
  

  Note : Expires est disponible depuis plus longtemps que Max-Age, cependant Max-Age est moins sujet aux erreurs et prend le pas lorsque les deux sont définis. La raison en est que lorsque vous définissez une date et une heure pour Expires, elles sont relatives au client sur lequel le cookie est défini. Si le serveur est réglé sur une heure différente, cela pourrait provoquer des erreurs.

• Session cookies — cookies sans attribut Max-Age ou Expires — sont supprimés lorsque la session en cours se termine. Le navigateur définit quand la « session en cours » se termine, et certains navigateurs utilisent la restauration de session lors du redémarrage. Cela peut entraîner la persistance indéfinie des cookies de session.

  Note : Si votre site authentifie des utilisateur·ice·s, il doit régénérer et renvoyer les cookies de session, même ceux qui existent déjà, chaque fois qu'un·e utilisateur·ice s'authentifie. Cette approche aide à prévenir les attaques de fixation de session ^(angl.), où un tiers peut réutiliser la session d'un·e utilisateur·ice.

Pour supprimer immédiatement un cookie, définissez à nouveau le cookie avec le même nom, chemin et domaine (si défini), et définissez son attribut Expires à une date passée ou son attribut Max-Age à 0 ou négatif. Cela indique au navigateur de supprimer le cookie immédiatement. Par exemple :

Set-Cookie: id=a3fWa; Max-Age=0

Vous pouvez également effacer tous les cookies associés à un domaine enregistrable en utilisant l'en-tête de réponse Clear-Site-Data. Par exemple, l'en-tête suivant envoyé depuis https://toto.exemple.com/ effacerait tous les cookies envoyés par exemple.com et tous ses sous-domaines, tels que tout.tata.exemple.com.

Clear-Site-Data: "cookies"

Il existe certaines techniques conçues pour recréer des cookies après leur suppression. Celles-ci sont connues sous le nom de « cookies zombies ». Ces techniques violent les principes de confidentialité et de contrôle des utilisateur·ice·s, peuvent enfreindre les réglementations sur la protection des données et pourraient exposer un site Web les utilisant à des responsabilités légales.

Mettre à jour les valeurs de cookies

Pour mettre à jour un cookie avec HTTP, le serveur peut envoyer un en-tête Set-Cookie avec le nom du cookie existant et une nouvelle valeur. Par exemple :

Set-Cookie: id=nouvelle-valeur

Il existe plusieurs raisons pour lesquelles vous pourriez vouloir faire cela, par exemple si un·e utilisateur·ice a mis à jour ses préférences et que l'application souhaite refléter les changements dans les données côté client (vous pourriez également le faire avec un mécanisme de stockage côté client tel que le stockage web).

Mettre à jour les cookies avec JavaScript

Dans le navigateur, vous pouvez créer de nouveaux cookies avec JavaScript en utilisant la propriété Document.cookie, ou l'API asynchrone Cookie Store. Notez que tous les exemples ci-dessous utilisent Document.cookie, car c'est l'option la plus largement supportée/établie.

document.cookie = "delicieux_cookie=choco";
document.cookie = "savoureux_cookie=fraise";

Vous pouvez également accéder aux cookies existants et définir de nouvelles valeurs pour ceux-ci :

console.log(document.cookie);
// affiche "delicieux_cookie=choco; savoureux_cookie=fraise"

document.cookie = "delicieux_cookie=baie_des_bois";

console.log(document.cookie);
// affiche "delicieux_cookie=choco; savoureux_cookie=fraise; delicieux_cookie=baie_des_bois"

Pour des raisons de sécurité, vous ne pouvez pas modifier les valeurs des cookies en envoyant directement un en-tête Cookie mis à jour lors de l'initiation d'une requête, par exemple avec fetch() ou XMLHttpRequest.

Il existe de bonnes raisons pour lesquelles vous ne devriez pas permettre à JavaScript de modifier les cookies. Vous pouvez empêcher JavaScript d'accéder à un cookie en définissant l'attribut HttpOnly lors de sa création. Consultez la section Sécurité pour plus de détails.

Sécurité

Lorsque vous stockez des informations dans des cookies, par défaut toutes les valeurs des cookies sont visibles et peuvent être modifiées par l'utilisateur·ice final. Vous ne voulez vraiment pas que vos cookies soient mal utilisés — par exemple, accessibles/modifiés par des acteurs malveillants, ou envoyés à des domaines où ils ne devraient pas être envoyés. Les conséquences potentielles peuvent aller de l'ennuyeux — des applications qui ne fonctionnent pas ou qui présentent un comportement étrange — au catastrophique. Un·e criminel·le pourrait par exemple voler un identifiant de session et l'utiliser pour définir un cookie qui donne l'impression qu'il est connecté en tant qu'autre personne, prenant ainsi le contrôle de son compte bancaire ou de commerce électronique.

Vous pouvez sécuriser vos cookies de différentes manières, qui sont examinées dans cette section.

Bloquer l'accès à vos cookies

Vous pouvez vous assurer que les cookies sont envoyés de manière sécurisée et ne sont pas accessibles par des parties ou des scripts non autorisés de deux manières : avec l'attribut Secure et l'attribut HttpOnly :

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

• Un cookie avec l'attribut Secure n'est envoyé au serveur qu'avec une requête chiffrée par le protocole HTTPS. Il n'est jamais envoyé avec HTTP non sécurisé (sauf sur localhost), ce qui signifie que les attaquant·e·s de la personne au milieu ne peuvent pas y accéder facilement. Les sites non sécurisés (avec http: dans l'URL) ne peuvent pas définir de cookies avec l'attribut Secure. Cependant, ne supposez pas que Secure empêche tout accès aux informations sensibles dans les cookies. Par exemple, quelqu'un ayant accès au disque dur du client (ou à JavaScript si l'attribut HttpOnly n'est pas défini) peut lire et modifier les informations.

• Un cookie avec l'attribut HttpOnly ne peut pas être accédé par JavaScript, par exemple en utilisant Document.cookie ; il ne peut être accédé que lorsqu'il atteint le serveur. Les cookies qui persistent les sessions utilisateur·ice, par exemple, devraient avoir l'attribut HttpOnly défini — il serait vraiment dangereux de les rendre disponibles à JavaScript. Cette précaution aide à atténuer les attaques de type cross-site scripting (XSS).

Définir où les cookies sont envoyés

Les attributs Domain et Path définissent la portée d'un cookie, c'est-à-dire les URL vers lesquelles le cookie peut être envoyé.

• L'attribut Domain indique les hôtes qui peuvent recevoir un cookie. Si cet attribut est défini, les cookies sont disponibles sur le serveur défini et ses sous-domaines. Par exemple, si vous définissez Domain=mozilla.org depuis mozilla.org, les cookies sont disponibles sur ce domaine et ses sous-domaines comme developer.mozilla.org.

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Domain=mozilla.org
  

  Si l'en-tête Set-Cookie ne définit pas d'attribut Domain, les cookies sont disponibles sur le serveur qui les définit mais pas sur ses sous-domaines. Par conséquent, définir l'attribut Domain est moins restrictif que de l'omettre. Notez qu'un serveur ne peut définir l'attribut Domain que sur son propre domaine ou un domaine parent, pas sur un sous-domaine ou un autre domaine. Ainsi, par exemple, un serveur avec le domaine foo.example.com pourrait définir l'attribut sur example.com ou foo.example.com, mais pas sur bar.foo.example.com ou elsewhere.com (les cookies seraient néanmoins envoyés aux sous-domaines tels que bar.foo.example.com). Voir Domaines invalides pour plus de détails.

• L'attribut Path indique un chemin URL qui doit exister dans l'URL demandée pour envoyer l'en-tête Cookie. Par exemple :

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Path=/docs
  

  Le caractère %x2F (/) est considéré comme un séparateur de répertoires, et les sous-répertoires correspondent également. Par exemple, si vous définissez Path=/docs, ces chemins de requête correspondent :

  • /docs
  • /docs/
  • /docs/Web/
  • /docs/Web/HTTP

  En revanche, pour ces chemins, les cookies ne sont pas ajoutés :

  • /
  • /docsets
  • /fr/docs

  Note : L'attribut Path permet de contrôler quels cookies le navigateur envoie en fonction des différentes parties d'un site. Il n'est pas destiné à être une mesure de sécurité et ne protège pas contre la lecture non autorisée du cookie à partir d'un chemin différent.

Contrôler les cookies tiers avec SameSite

L'attribut SameSite permet aux serveurs de définir si et quand les cookies sont envoyés avec des requêtes inter-sites (depuis d'autres sites) — c'est-à-dire des cookies tiers. Les requêtes inter-sites sont des requêtes où le site (le domaine enregistrable) et/ou le schéma (http ou https) ne correspondent pas au site que l'utilisateur·ice visite actuellement. Cela inclut les requêtes envoyées lorsque des liens sont cliqués sur d'autres sites pour naviguer vers votre site, ainsi que toute requête envoyée par du contenu tiers intégré.

SameSite aide à prévenir la fuite d'informations, à préserver la vie privée de l'utilisateur·ice et à fournir une certaine protection contre les attaques de type cross-site request forgery. Il prend trois valeurs possibles : Strict, Lax et None :

• Strict oblige le navigateur à n'envoyer le cookie qu'en réponse à des requêtes provenant du site d'origine du cookie. Cela devrait être utilisé lorsque vous avez des cookies liés à des fonctionnalités qui sont toujours derrière une navigation initiale, comme l'authentification ou le stockage des informations du panier d'achat.

  http

  Set-Cookie: cart=110045_77895_53420; SameSite=Strict
  

  Note : Les cookies utilisés pour des informations sensibles devraient également avoir une durée de vie courte.

• Lax est similaire, sauf que le navigateur envoie également le cookie lorsque l'utilisateur·ice navigue vers le site d'origine du cookie (même si l'utilisateur·ice provient d'un site différent). Cela est utile pour les cookies affectant l'affichage d'un site — par exemple, vous pouvez avoir des informations sur les produits partenaires avec un lien d'affiliation sur votre site. Lorsque ce lien est suivi vers le site partenaire, ils peuvent vouloir définir un cookie indiquant que le lien d'affiliation a été suivi, ce qui affiche une bannière de récompense et offre une réduction si le produit est acheté.

  http

  Set-Cookie: affiliate=e4rt45dw; SameSite=Lax
  

• None définit que les cookies sont envoyés à la fois pour les requêtes provenant du site d'origine et pour les requêtes inter-sites. Cela est utile si vous souhaitez envoyer des cookies avec des requêtes effectuées à partir de contenu tiers intégré dans d'autres sites, par exemple, des fournisseurs de technologies publicitaires ou d'analytique. Notez que si SameSite=None est défini, l'attribut Secure doit également être défini — SameSite=None nécessite un contexte sécurisé.

  http

  Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
  

Si aucun attribut SameSite n'est défini, le cookie est traité comme Lax par défaut.

Préfixes de cookie

En raison de la conception du mécanisme des cookies, un serveur ne peut pas confirmer qu'un cookie a été défini à partir d'une origine sécurisée ni même indiquer où un cookie a été initialement défini.

Une application sur un sous-domaine peut définir un cookie avec l'attribut Domain, ce qui donne accès à ce cookie sur tous les autres sous-domaines. Ce mécanisme peut être abusé dans une attaque de fixation de session ^(angl.).

En tant que mesure de défense en profondeur ^(angl.), vous pouvez utiliser des préfixes de cookie pour imposer des restrictions spécifiques sur les attributs d'un cookie dans les agents utilisateurs compatibles. Tous les préfixes de cookie commencent par un double underscore (__) et se terminent par un tiret (-). Quatre préfixes sont disponibles :

• __Secure- : Les cookies dont le nom commence par __Secure- doivent être définis avec l'attribut Secure par une page sécurisée (HTTPS).
• __Host- : Les cookies dont le nom commence par __Host- doivent être définis avec l'attribut Secure par une page sécurisée (HTTPS). De plus, ils ne doivent pas avoir d'attribut Domain défini, et l'attribut Path doit être défini sur /. Cela garantit que ces cookies ne sont envoyés qu'à l'hôte qui les a définis, et non à un autre hôte du domaine. Cela garantit également qu'ils sont définis pour l'ensemble de l'hôte et ne peuvent pas être remplacés sur un chemin quelconque de cet hôte. Cette combinaison produit un cookie qui est aussi proche que possible de traiter l'origine comme une frontière de sécurité.
• __Http- : Les cookies dont le nom commence par __Http- doivent être définis avec l'attribut Secure par une page sécurisée (HTTPS) et doivent en outre avoir l'attribut HttpOnly défini pour prouver qu'ils ont été définis par l'en-tête Set-Cookie (ils ne peuvent pas être définis ou modifiés avec des fonctionnalités JavaScript telles que Document.cookie ou l'API Cookie Store).
• __Host-Http- : Les cookies dont le nom commence par __Host-Http- doivent être définis avec l'attribut Secure par une page sécurisée (HTTPS) et doivent avoir l'attribut HttpOnly défini pour prouver qu'ils ont été définis par l'en-tête Set-Cookie. De plus, ils ont également les mêmes restrictions que les cookies préfixés __Host-. Cette combinaison produit un cookie qui est aussi proche que possible de traiter l'origine comme une frontière de sécurité tout en garantissant aux développeur·euse·s et aux opérateur·ice·s de serveur que sa portée est limitée aux requêtes HTTP.

Le navigateur rejette les cookies avec ces préfixes qui ne respectent pas leurs restrictions. Comme le serveur d'application ne vérifie qu'un nom de cookie spécifique pour déterminer si l'utilisateur·ice est authentifié·e ou si un jeton CSRF est correct, cela agit effectivement comme une mesure de défense contre la fixation de session ^(angl.).

Pour plus d'informations sur les préfixes de cookie et l'état actuel de la prise en charge par les navigateurs, consultez la section Préfixes de l'article de référence Set-Cookie.

Pistage et vie privée

Comme nous l'avons mentionné précédemment, l'attribut SameSite peut être utilisé pour contrôler quand les cookies tiers sont envoyés, ce qui peut aider à préserver la vie privée des utilisateur·ice·s. La vie privée est une considération très importante lors de la création de sites web, car lorsqu'elle est bien gérée, elle peut renforcer la confiance des utilisateur·ice·s. À l'inverse, une mauvaise gestion peut complètement éroder cette confiance et causer toutes sortes de problèmes.

Les cookies tiers peuvent être définis par du contenu tiers intégré dans des sites avec des <iframe>. Ils ont de nombreuses utilisations légitimes, notamment le partage d'informations sur le profil utilisateur·ice, le comptage des impressions publicitaires ou la collecte d'analyses sur différents domaines liés.

Cependant, les cookies tiers peuvent également être utilisés pour créer des expériences utilisateur intrusives et inquiétantes. Un serveur tiers peut créer un profil de l'historique de navigation et des habitudes d'un·e utilisateur·ice en se basant sur les cookies envoyés par le même navigateur lorsqu'il accède à plusieurs sites. L'exemple classique est lorsque vous recherchez des informations sur un produit sur un site et que vous êtes ensuite poursuivi sur le web par des publicités pour des produits similaires où que vous alliez.

Les fournisseurs de navigateurs savent que les utilisateur·ice·s n'aiment pas ce comportement et, par conséquent, ont tous commencé à bloquer les cookies tiers par défaut, ou du moins ont prévu de le faire. Les cookies tiers (ou simplement les cookies de suivi) peuvent également être bloqués par d'autres paramètres du navigateur ou extensions.

Consultez notre article sur les cookies tiers pour des informations détaillées sur les cookies tiers, les problèmes qui y sont associés et les alternatives disponibles. Consultez notre page d'accueil sur la vie privée pour plus d'informations sur la vie privée en général.

Régulations relatives aux cookies

Les législations ou régulations qui couvrent l'utilisation des cookies incluent :

• La réglementation générale sur la protection des données (GDPR) dans l'Union européenne
• La directive ePrivacy dans l'UE
• La California Consumer Privacy Act

Ces régulations ont une portée mondiale. Elles s'appliquent à tout site sur le World Wide Web auquel des utilisateur·ice·s de ces juridictions accèdent (l'UE et la Californie, avec la réserve que la loi californienne ne s'applique qu'aux entités dont le chiffre d'affaires brut dépasse 25 millions USD, entre autres).

Ces régulations incluent des exigences telles que :

• Informer les utilisateur·ice·s que votre site utilise des cookies.
• Permettre aux utilisateur·ice·s de refuser de recevoir certains ou tous les cookies.
• Permettre aux utilisateur·ice·s d'utiliser la majeure partie de votre service sans recevoir de cookies.

Il peut y avoir d'autres régulations qui régissent l'utilisation des cookies dans votre localité. Il vous incombe de connaître et de respecter ces régulations. Il existe des entreprises qui proposent du code de « bannière de cookies » pour vous aider à vous conformer à ces régulations.

Voir aussi

• Les en-têtes HTTP associés : Set-Cookie, Cookie
• Les API JavaScript associées : Document.cookie, Navigator.cookieEnabled, l'API Cookie Store
• Les cookies tiers
• Spécification des cookies : RFC 6265 ^(angl.)
• Cookies, le RGPD et la directive ePrivacy ^(angl.)