Headers, cookies et sessions

Prérequis : cours 7.1 ; headers, JSON et cookies, sessions et cookies.

Pourquoi

Auth qui « saute », panier qui se vide, langue qui ne reste pas : 90 % de ces mystères sont des histoires de cookies/headers. Et côté sécu, quelques headers valent plus qu'un WAF mal configuré.

Concepts

• Cookie : petit texte que le serveur pose (Set-Cookie) et que le navigateur renvoie (Cookie). Attributs : HttpOnly (invisible au JS — anti-XSS), Secure (HTTPS seul), SameSite (Lax/Strict = anti-CSRF, None = cross-site explicite), Max-Age.
• Session serveur : le cookie ne contient qu'un identifiant, les données vivent côté serveur (base, Redis). Voler le cookie = voler la session → d'où HttpOnly + Secure + rotation.
• Authorization: Bearer : le token dans le header (pas en cookie) pour les API : pas de CSRF possible (le navigateur ne l'envoie pas tout seul), mais XSS = vol direct — d'où stockage prudent (mémoire, pas localStorage).
• Headers sécu (rappel cours DevOps 3.3) : HSTS, nosniff, DENY, CSP. Ici on comprend le pourquoi : chacun bouche une attaque précise.

Exemple : voir ce qui circule

curl -sI https://example.com | grep -i "set-cookie\|strict\|content-security"
# DevTools → Application → Cookies : HttpOnly coché ? Secure ? SameSite ?

Cas réel

« Déconnecté à chaque refresh » : cookie de session sans Secure derrière un proxy qui force HTTPS… ou cookie posé sur le mauvais domaine (Domain= mal configuré). DevTools → le cookie est-il renvoyé ? Non = attributs à revoir, pas « bug d'auth ».

Pièges

• SameSite=None sans Secure : refusé par les navigateurs — combo obligatoire.
• Token en localStorage « pour simplifier » : XSS = vol. Mémoire ou cookie HttpOnly selon le cas.
• CORS confondu avec l'auth : Access-Control-Allow-Origin: * + credentials = faille béante, pas une rustine.

À retenir

Cookie = transport, session = serveur ; HttpOnly + Secure + SameSite par défaut ; Bearer en header pour les API.