CSRF Protection 2026

Cross-site request forgery. The defenses.

SameSite cookies

Cross-Site Request Forgery (CSRF) is the attack where a malicious site tricks a victim's browser into making authenticated requests to your application. The browser automatically attaches the user's cookies; the application processes the request as if it were legitimate. The defense is layered: SameSite cookies at the browser level, CSRF tokens at the application level, and Origin verification at the gateway level.

What SameSite cookies actually do:

• SameSite=Lax or Strict.: The SameSite attribute on a cookie tells the browser when to attach it. Lax: only on top-level navigation; Strict: only on same-site requests entirely. Either setting prevents the cookie from being attached on cross-site fetch requests, which is the SameSite-specific defense against CSRF.
• Browser-level protection.: Modern browsers (Chrome, Firefox, Safari, Edge) all default new cookies to SameSite=Lax. Cookies set without explicit SameSite are treated as Lax. The defense is automatic for new sites built today.
• Lax allows top-level navigation.: When a user clicks a link from another site, the cookie is attached. This preserves the legitimate use case (user clicks an email link to view their order) while blocking the attack case (malicious site issues fetch with credentials).
• Strict is more aggressive.: Strict refuses to send the cookie even on top-level navigation from another site. The user clicks a link, lands on your site, and is logged out. This breaks the email-link use case but provides the strongest CSRF protection. Most teams use Lax for session cookies and Strict for high-sensitivity cookies.
• Sufficient for most CSRF cases.: SameSite alone catches the majority of practical CSRF attacks. Older browsers still ignore SameSite, and some edge cases (subdomains, complex authentication flows) need the additional layers. But SameSite is the floor of modern CSRF defense.

SameSite cookies are the cheapest and most effective CSRF defense. The configuration is one attribute; the protection is automatic.

CSRF tokens

The traditional CSRF defense is the per-session anti-forgery token. The application generates a random token, stores it in the session, and includes it in every form. State-changing requests must include the token; requests without it are rejected. CSRF tokens predate SameSite by a decade and remain useful as a defense-in-depth layer.

• Per-session token validation.: The token is generated when the session starts, stored server-side, and included in every form rendered to the user. State-changing requests (POST, PUT, DELETE) must include the token in a hidden field or header. The server validates the token matches the session before processing.
• Defense in depth.: CSRF tokens catch the cases SameSite cannot. Older browsers, subdomain takeover scenarios, complex authentication flows. The token is independent of the cookie attribute; it works even when SameSite would not.
• Framework-provided.: Modern web frameworks ship CSRF token handling as a built-in middleware. Rails, Django, ASP.NET, Spring all provide it. The developer gets the protection by default; opting out requires a deliberate code change.
• Pattern: double-submit cookie.: A variant where the token is stored in a cookie (with HttpOnly false so JavaScript can read it) and the JavaScript adds it as a header on requests. The server validates that the cookie value matches the header value. This works without server-side session state.
• Token rotation.: The token rotates per session and ideally per high-sensitivity operation. A token leaked once does not provide indefinite access; the next session has a different one. Rotation is automatic with proper framework integration.

CSRF tokens are the second layer. Combined with SameSite cookies, the protection is robust against current attack patterns. Either layer alone has gaps; both layers together close most of them.

Origin check

The third layer is Origin and Referer header verification at the application or gateway level. Modern browsers attach Origin to all cross-origin requests; verifying it on state-changing requests catches CSRF attempts that somehow slipped through the other layers.

• Verify Origin header on state-changing requests.: Every POST, PUT, DELETE checks the Origin header. If the Origin is not on the application's allowlist (its own domain plus any explicitly trusted ones), the request is rejected. The check is a few lines of middleware code.
• Falls back to Referer for older browsers.: Some legacy browsers omit Origin on same-origin requests. In those cases, fall back to the Referer header. Both contain the site that initiated the request; either can be checked.
• Catches CSRF attempts.: An attacker's malicious site cannot forge the Origin header (the browser sets it). Requests with a wrong Origin are unambiguously cross-site requests. The check is mechanical and reliable.
• Cheap to implement.: The Origin check is configuration-level work. Most API gateways and web frameworks support it natively. The cost is minutes; the protection is permanent.
• Combine with the other layers.: Origin checking does not replace SameSite or CSRF tokens; it adds a third verification. The combination is what produces the layered defense. Each layer catches what the others might miss.

SameSite cookies, CSRF tokens, and Origin verification together produce the modern CSRF defense. Nova AI Ops integrates with API gateway audit streams to surface CSRF-protection violations (requests that bypassed expected origins, missing CSRF tokens on state-changing endpoints) so the security posture stays defended over time as the application evolves.