Aller au contenu

Cookie : Cookie HTTP (HTTP cookie)

Sécurité

Petit fragment de texte (une paire nom=valeur) qu'un serveur web dépose dans le navigateur, et que celui-ci renvoie automatiquement à chaque requête vers le même site. C'est le moyen le plus répandu de donner une mémoire à HTTP, un protocole qui oublie tout d'une requête à l'autre.

Diagramme de séquence entre deux acteurs, le navigateur et le serveur. 1. Le navigateur envoie une requête de connexion avec ses identifiants. 2. Le serveur répond avec l'en-tête Set-Cookie: session=abc. 3. Le navigateur stocke le cookie avec son domaine, son chemin et son expiration. 4. S'il s'agit du même domaine et que le cookie n'a pas expiré, le navigateur renvoie l'en-tête Cookie: session=abc. 5. Si le serveur reconnaît la session, il renvoie une page personnalisée.

Fonctionnement : Le serveur envoie l'en-tête Set-Cookie dans sa réponse ; le navigateur stocke la valeur puis la renvoie dans l'en-tête Cookie à chaque requête vers le domaine et le chemin concernés. Le mécanisme est normalisé par la RFC 6265. Le cookie ne porte le plus souvent qu'un identifiant opaque : le navigateur présente le ticket, le serveur garde le registre du vestiaire.

Attributs de sécurité : Secure limite l'envoi aux connexions HTTPS, HttpOnly rend le cookie invisible pour JavaScript (ce qui freine le vol par XSS), et SameSite restreint l'envoi lors des requêtes venues d'autres sites (rempart contre le CSRF). Un cookie de session qui n'a aucun de ces trois attributs est une invitation, pas un identifiant.

Session ou persistant : Sans Expires ni Max-Age, le cookie disparaît à la fermeture du navigateur ; avec, il survit jusqu'à la date indiquée. Un cookie de session porte souvent l'identifiant de connexion : le voler revient à voler la session, sans avoir besoin du mot de passe.

Cookies tiers : Déposé par un domaine autre que celui qu'on visite, le cookie tiers sert surtout au pistage publicitaire. Safari le bloque par défaut, Firefox le cloisonne site par site pour qu'il ne suive plus personne, et Chrome, après avoir annoncé puis abandonné sa suppression, le garde. Le bandeau de consentement, lui, se porte à merveille : preuve qu'un problème de vie privée peut toujours se résoudre en un clic de plus.

Ce qui arrive si on s'en passe

Sans cookie, HTTP ne relie aucune requête à la précédente : le serveur ne sait plus qu'un visiteur s'est déjà authentifié, et chaque page protégée redemande l'identification ou refuse l'accès. Paniers, préférences et sessions disparaissent à chaque navigation. Pour combler ce manque, l'identifiant de session finit souvent dans l'URL ; il apparaît alors dans l'historique du navigateur, dans les journaux des serveurs et des proxys, dans l'en-tête Referer transmis aux sites tiers et dans les liens copiés ou partagés. Toute personne qui le récupère peut alors reprendre la session. L'autre solution de contournement consiste à renvoyer les identifiants à chaque requête, ce qui multiplie les occasions de les intercepter. Le serveur perd aussi le moyen de rattacher une suite d'actions à une même session, ce qui complique la corrélation des journaux lors d'une analyse.

Explication de la marmotte

Un site web a la mémoire d'un poisson rouge : à chaque nouvelle page, il oublie qui tu es. Pour s'en sortir, il donne à ton navigateur (le programme qui te sert à visiter les sites) un petit ticket, comme celui du vestiaire à une soirée. Ton navigateur garde ce ticket et le montre à chaque nouvelle page. Le site le reconnaît : « Ah, c'est toi, tu es connecté, et ton panier contient deux livres. » Si quelqu'un vole ton ticket, il peut se faire passer pour toi. Et certains sites posent des tickets uniquement pour suivre où tu te promènes sur internet : c'est pour ça que tant de fenêtres te demandent ton accord.

Où ce terme est utilisé

← Tout le glossaire