CSRF in 2026: Why SameSite Doesn’t Solve Everything

Last updated: April 26, 2026

Cross-Site Request Forgery (CSRF) was supposed to be solved by SameSite cookies. Browsers default to SameSite=Lax. CSRF tokens are framework-default. So why do we still find CSRF on Indian web pentests in 2026? Because SameSite has gaps, frameworks have config flags, and certain endpoint patterns remain vulnerable. This article covers modern CSRF — what SameSite catches, what it misses, and the defences that close every variant.

What SameSite catches

SameSite=Lax (the modern default) blocks cookies on cross-site POST/PUT/DELETE requests. Browsers don’t send cookies when:

• The user clicks a form on attacker.com that POSTs to victim.com
• JavaScript on attacker.com sends a fetch() to victim.com (cookie not included)

This was the canonical CSRF for two decades. SameSite=Lax kills it.

What SameSite misses

1. SameSite=None for legitimate cross-site needs

Federated SSO, third-party widgets, and embedded SaaS often require SameSite=None. Many legacy applications set SameSite=None unnecessarily and lose CSRF protection.

2. GET-based state changes

SameSite=Lax allows top-level GET requests with cookies. If your application has GET endpoints that change state — /account/delete?id=123, /transfer?to=attacker&amount=1000 — CSRF still works via image tags or anchor clicks.

Mitigation: state changes via POST/PUT/DELETE, never GET. RESTful conventions exist for a reason.

3. SameSite=Lax 2-minute window for top-level navigation

Some browsers (notably Chrome’s “Lax+POST” implementation) allow cross-site POST cookies for a 2-minute window after cookie creation. The window is closing in newer browsers but remains a gap.

4. Subdomain CSRF

SameSite is “Site” — same eTLD+1. attacker.example.com is same-site as victim.example.com. If subdomain takeover is possible, or if attacker controls a subdomain, CSRF still works.

5. CORS-misconfigured APIs

If the API has Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true (browser refuses, but custom configurations sometimes work), CSRF reverts to baseline.

6. WebSocket / EventSource

Cross-Origin WebSocket Hijacking — if the WebSocket handshake doesn’t validate Origin and authenticates via cookies, attacker establishes WS from their site.

The fix in modern apps

• SameSite=Strict for sensitive cookies where possible (some UX trade-offs).
• CSRF tokens for state-changing requests as defence-in-depth, even with SameSite.
• Origin / Referer validation server-side — verify the request came from your origin.
• Custom request headers for AJAX — browsers don’t send custom headers cross-site without preflight.
• Double-submit cookie pattern for stateless CSRF protection.
• Avoid GET state changes — RESTful semantics.

Detection

• Audit every state-changing endpoint for CSRF protection.
• Burp Pro’s CSRF Scanner finds missing protections.
• Test with fetch(...) from a different origin to confirm CORS / SameSite enforcement.

The takeaway

SameSite is good but not complete CSRF protection. Layer it with tokens, Origin validation, and proper HTTP method semantics. Audit your application’s state-changing endpoints; any missing CSRF protection is a finding, regardless of cookie configuration.