Cookies et sessions : comment un site te reconnaît

Un protocole qui oublie tout

Chaque requête HTTP est traitée indépendamment des autres : c’est ce qu’on appelle un protocole sans état (« stateless »). Sans mécanisme additionnel, un serveur ne peut pas savoir que la requête qui arrive vient du même navigateur que celle reçue dix secondes plus tôt, y compris si un identifiant vient de se connecter entre les deux.

Pourtant, la plupart des sites « se souviennent » qu’on est connecté d’une page à l’autre. Ce souvenir n’a rien de magique : il repose entièrement sur un en-tête vu au chapitre précédent, décliné pour cet usage précis.

Le cookie, une donnée que le client renvoie lui-même

Quand un serveur veut qu’un client conserve une information, il l’envoie via l’en-tête Set-Cookie dans une réponse :

HTTP/1.1 200 OK
Set-Cookie: session_id=a3f9c2e1; HttpOnly; Secure; SameSite=Lax

Le navigateur stocke cette valeur, puis la renvoie automatiquement au serveur à chaque requête suivante vers ce même domaine, via l’en-tête Cookie :

GET /compte HTTP/1.1
Host: exemple.test
Cookie: session_id=a3f9c2e1

Le serveur retrouve alors, grâce à cet identifiant (session_id), les informations associées à la session ouverte : qui est connecté, ce qu’il y a dans son panier, etc. Le cookie ne contient généralement pas ces informations lui-même, seulement une clé qui permet au serveur de les retrouver de son côté.

Trois attributs qui renforcent un cookie

Les attributs ajoutés après la valeur du cookie (HttpOnly, Secure, SameSite dans l’exemple ci-dessus) ne sont pas décoratifs :

• HttpOnly : rend le cookie invisible à JavaScript (document.cookie), pour qu’un script malveillant injecté sur la page ne puisse pas le lire et l’exfiltrer.
• Secure : n’envoie le cookie que sur une connexion HTTPS, jamais en clair sur une connexion HTTP non chiffrée.
• SameSite : limite l’envoi du cookie aux requêtes provenant du même site (ou l’autorise avec restrictions), pour réduire l’exposition à certaines attaques déclenchées depuis un site tiers.