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.
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é
- Attributs du cookie de session (62 occurrences)
- Comment empêcher une attaque de fixation de session (14 occurrences)
- CWE-352 : falsification de requête inter-sites (CSRF) (11 occurrences)
- Cross-site scripting (XSS) : mécanisme, variantes et défenses (9 occurrences)
- Attaque MIME sniffing par fichier téléversé (8 occurrences)
- Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades (8 occurrences)
- Gestion de la CMP : création et intégration technique (8 occurrences)
- La politique de même origine : ce que le navigateur cloisonne vraiment (8 occurrences)
- Mentions légales (7 occurrences)
- WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites (6 occurrences)
