Double-Submit Cookie Pattern (CSRF defense)

Le Double-Submit Cookie Pattern est une défense CSRF stateless où le server set un token random dans un cookie ET attend la même valeur dans request body/header. Attaquant CSRF ne peut pas lire le cookie (Same-Origin Policy) donc ne peut pas inclure la valeur dans son request forgé.

Workflow :
(1) Server génère random token (≥256 bits crypto-secure) et set cookie `XSRF-TOKEN=abc123` (non-HttpOnly nécessaire pour que JS le lise).
(2) Sur chaque state-changing request (POST/PUT/DELETE), client JavaScript read cookie value et inclut dans header `X-XSRF-TOKEN: abc123` ou dans form field.
(3) Server verify cookie value == header/body value. Match → process. Mismatch → reject.

Why works : attacker site forging request cross-origin can submit form/AJAX, mais NE peut PAS lire victim's cookie value (Same-Origin Policy blocks reading cross-origin cookies). Cookie value submitted automatically with request (since attacker forged request to victim's domain), mais attacker NE peut PAS include matching header/body since doesn't know value.

Avantages vs synchronizer token :
(1) **Stateless** — server doesn't need to store tokens (less DB load, scales easier).
(2) **Simpler implementation** — no session storage required.
(3) **Microservices friendly** — works across services without shared session store.

Limitations :
(1) **Cookie integrity** — if attacker can set cookies on victim's domain (subdomain hijacking, MITM avec HTTPS broken), can match values. Mitigation : **Signed cookies** (HMAC token) — value tied à user session, attacker can't forge valid.
(2) **Non-HttpOnly required** — JS must read, so vulnerable to XSS. If XSS present, attacker reads cookie and forges matching header anyway. Defense in depth : XSS mitigation (CSP) + cookie pattern.
(3) **Subdomain attacks** — if cookies set Domain=.example.com, subdomain XSS or compromise can read/set. Mitigation : avoid sharing CSRF cookies across subdomains.

Framework support :
- **Angular** : built-in support via HttpClient + XSRF-TOKEN cookie convention.
- **AngularJS** : same.
- **Django** : CSRF middleware double-submit option.
- **Spring Security** : CsrfTokenRepository options.

Vs synchronizer token pattern (server-stored) : Synchronizer slightly more secure but stateful. Double-submit popular SPA + REST APIs.

Nouvelle defense : **SameSite=Lax cookies** provide significant CSRF protection without CSRF tokens (Chrome 80+ default). Pour state-changing requests cross-origin, SameSite=Lax blocks. Defense in depth : combine SameSite + double-submit pour belt-and-suspenders. Compétences Security+, CISSP, OSCP.