CSRF Token vs SameSite: Do You Still Need Tokens in 2026?
CSRF token vs SameSite in 2026: SameSite=Lax is the browser default and good defense-in-depth, but it doesn't stop every CSRF attack. Here's the head-to-head comparison and exactly when you still need tokens.
The verdict up front: SameSite cookies are defense-in-depth; anti-CSRF tokens remain the primary control in 2026. Since browsers made SameSite=Lax the default, a lot of teams quietly dropped their tokens — and OWASP still recommends the synchronizer token pattern as the primary defense. The reason: Lax blocks the classic forged POST, but it leaves real gaps that tokens close. Here's the full head-to-head, runnable token code, and the exact scenarios where Lax alone is (and isn't) enough. CSRF Token vs SameSite: The Choice, Stated Plainly CSRF works because browsers attach your session cookie to any request aimed at your bank's domain — even a request forged by an attacker's page. The two defenses solve this from opposite ends: tokens make each request prove it came from your own UI, while SameSite tells the browser when to withhold the cookie in the first place. The question isn't which one works — it's which one covers the attack shapes your app actually faces. CSRF Tokens: Strengths and Weaknesses The synchronizer token pattern is the OWASP-recommended primary defense: the server generates a random, unpredictable value per session, shares it with the client (in a readable companion cookie or the response body), and the client echoes it back in a header or form field on every state-changing request. The attacker's page can make the browser *send* the session cookie, but same-origin policy stops it from *reading* the token — so it can't forge a valid request. Strengths: Covers every request shape. GET, POST, top-level navigations, fetch — anything without a valid token is rejected, regardless of how the request was initiated. Independent of browser behavior. Works on old browsers and embedded WebViews that ignore the SameSite…