Pour comprendre l’intérêt des cookies, vous devez avant tout vous rappeler que HTTP est un protocole sans état. Cela implique notamment que le serveur n’a à priori aucun moyen d’établir un lien entre deux requêtes provenant d’un même client.
Cette particularité du HTTP peut rapidement devenir très gênante en termes d’expérience utilisateur : imaginez le cas où un utilisateur se connecte sur un site ou si il a indiqué des préférences d’utilisation sur le site. Le serveur n’est à priori pas capable de conserver l’état entre deux requêtes HTTP et le client devra se reconnecter ou indiquer à nouveau ses préférences à chaque changement de page.
Les cookies permettent de maintenir une session avec état sur le protocole HTTP qui est normalement sans état. On va pouvoir les utiliser pour la gestion de session comme la mémorisation d’un identifiant de session, de l’état d’un panier d’achat etc. ou pour la mémorisation des préférences utilisateur.
Fonctionnement des cookies HTTP
Lorsqu’un client effectue une requête pour la première fois, le serveur peut attacher un ou plusieurs cookies avec sa réponse. Le client pourra ensuite renvoyer ces cookies avec les requêtes futures, afin de conserver un état entre deux requêtes.
Pour enregistrer un état, le serveur inclut un en-tête Set-Cookie dans la réponse HTTP. Cet en-tête va contenir une paire nom-valeur et des métadonnées associées (date d’expiration, domaine de validité, etc.). On appelle cet ensemble nom + valeur + métadonnée un cookie.
Par exemple, le serveur peut envoyer à l’agent utilisateur un cookie d’identifiant de session qu’on peut appeler SID (« Session ID ») et qui va posséder la valeur liée à la session courante afin de pouvoir immédiatement le ré-identifier par la suite ou encore un cookie contenant les préférences de l’utilisateur par rapport à la langue qu’on peut appeler « lang ». Ces cookies pourraient ressembler à cela :
Set-Cookie: SID=14322ac76654aa83; Path=/; Secure; HttpOnly
Set-Cookie: lang=fr-FR; Path=/; Domain=example.com
Ces cookies vont être stockés chez l’agent utilisateur (le client). Lorsque l’agent utilisateur effectue de nouvelles requêtes, il utilise les métadonnées et d’autres informations pour déterminer s’il faut renvoyer les paires nom / valeur dans un en-tête de requête Cookie. L’en-tête cookie pourrait ici ressembler à cela :
Cookie: SID=14322ac76654aa83; lang=fr-FR
Attributs des cookies HTTP
Les deux cookies définis ci-dessus sont composés de paires nom-valeur (SID=14322ac76654aa83 et lang=fr-FR) et également d’autres données qu’on appelle des attributs de cookie.
Ces attributs vont nous permettre de définir la durée de vie des cookies, le domaine sur lequel ils doivent être définis, les conditions d’envoi, etc. les cookies peuvent contenir les attributs suivants :
Expires;Max-Age;Domain;Path;Secure;HttpOnly;SameSite(pas encore standardisé mais bénéficiant déjà d’un support étendu).
Expires
L’attribut Expires indique la durée de vie maximale du cookie, représentée par la date et l’heure d’expiration du cookie.
Notez que l’agent utilisateur peut tout à fait supprimer un cookie avant la data indiquée par Expires, notamment pour des raisons de pression sur la mémoire ou pour des raisons de confidentialité / sécurité.
Max-Age
L’attribut Max-Age indique également la durée de vie maximale du cookie, cette fois-ci représentée par le nombre de secondes jusqu’à l’expiration du cookie. L’agent utilisateur n’est une nouvelle fois pas tenu de conserver le cookie pendant la durée spécifiée.
Certains vieux agents utilisateurs ne supportent pas Max-Age. Dans ce cas, l’attribut est ignoré.
Notez que si un cookie possède à la fois un attribut Max-Age et un attribut Expires, l’attribut Max-Age a la priorité et contrôle la date d’expiration du cookie.
Enfin, notez que si un cookie ne possède ni attribut Max-Age ni Expires alors le cookie aura une durée de vie égale à celle de la session courante.
Domain
L’attribut Domain spécifie les hôtes auxquels le cookie sera envoyé. Par exemple, si la valeur de l’attribut Domain est « example.com », l’agent utilisateur inclura le cookie dans l’en-tête Cookie pour des requêtes HTTP sur example.com, www.example.com et www.corp.example. com.
Si l’attribut Domain est omis, l’agent utilisateur renverra le cookie uniquement au serveur d’origine. Attention : certains agents utilisateurs existants traitent un attribut Domain absent comme si l’attribut était présent et contenait le nom d’hôte actuel.
Path
La portée de chaque cookie est limitée à un ensemble de chemins, contrôlé par l’attribut Path.
Si le serveur omet l’attribut Path, l’agent utilisateur utilisera le répertoire du composant de chemin de l’URL de demande comme valeur par défaut.
L’agent utilisateur inclura le cookie dans une requête HTTP uniquement si la partie chemin de l’URL de la requête correspond à (ou est un sous-répertoire de) l’attribut Path du cookie.
Notez que le caractère slash (/) est interprété comme un séparateur de répertoire .
Attention : bien que l’attribut Path semble utile pour isoler les cookies entre différents chemins au sein d’un hôte donné, il n’est pas fiable d’un point de vue sécurité.
Secure
L’attribut Secure limite la portée du cookie aux canaux « sécurisés » (où la notion de « sécurité » est définie par l’agent utilisateur).
Lorsqu’un cookie possède un attribut Secure, l’agent utilisateur n’inclut le cookie dans une requête HTTP que si celle-ci est transmise sur un canal sécurisé, généralement HTTP sur Transport Layer Security (TLS) c’est-à-dire HTTPS.
Attention : l’attribut Secure protège uniquement la confidentialité du cookie. Un attaquant peut écraser les cookies Secure d’un canal non sécurisé, ce qui perturbe leur intégrité.
HttpOnly
L’attribut HttpOnly limite la portée du cookie aux requêtes HTTP. En particulier, l’attribut indique à l’agent utilisateur d’omettre le cookie lors de l’accès aux cookies via des API non-HTTP (telles qu’une API de navigateur Web qui expose les cookies aux scripts).
Notez que l’attribut HttpOnly est indépendant de l’attribut Secure : un cookie peut avoir à la fois un attribut HttpOnly et un attribut Secure.
Samesite
L’attribut Samesite n’est pas encore standardisé mais bénéfice déjà d’un support étendu parmi les navigateurs les plus populaires.
Cet attribut permet d’indiquer qu’un cookie ne doit pas être envoyés avec des requêtes cross-site. Il offre une certaine protection contre les attaques de type cross-site request forgery (CSRF).
Création et gestion des cookies HTTP
En tant que webmaster ou que développeur, vous n’aurez pas à créer la plupart des cookies puisque ceux-ci vont être générés automatiquement par le serveur (dans le cas de cookies d’environnement) ou par le CMS (Content Management System) utilisé si celui-ci a bien été conçu.
Cependant, il y a des situations où vous allez devoir vous-même définir des cookies, notamment dans le cas où vous avez besoin de stocker quelque chose de très spécifique chez le client ou dans le cas où vous êtes amené à créer un site sans utiliser d’architecture préconçue.
Dans ce cas-là, il existe différents moyens de créer des cookies. Dans tous les cas, vous allez créer vos cookies en utilisant un langage côté serveur (PHP, Python, etc.) ou éventuellement du JavaScript. Pour plus d’informations à ce sujet, n’hésitez pas à lire mes cours où j’explique comment créer un cookie en PHP et comment créer un cookie en JavaScript.
