Cross-site request forgery exploits a browser's default behavior of automatically attaching cookies (including session cookies) to any request, even one initiated by a completely different, malicious website. Without CSRF protection, visiting an unrelated malicious page can silently trigger a real, authenticated action on your site — transferring funds, changing an email address — using your own logged-in session, without you ever knowingly interacting with your own site at all.
How the Attack Actually Works
An attacker hosts a page containing a form or script that submits a request to your site's endpoint — say, a fund-transfer endpoint. If you are logged into your site in the same browser, visiting the attacker's page can cause your browser to submit that request with your session cookie attached automatically, and your server, seeing a valid session, processes it as if you had submitted it yourself intentionally.
The Synchronizer Token Pattern
The standard defense: generate a unique, unpredictable token tied to the user's session, embed it in every form, and reject any state-changing request that does not include the correct matching token. An attacker's page has no way to know or guess this token, since it is tied to a session the attacker cannot read.
Why GET Requests Should Never Change State
CSRF protection conventionally only applies to state-changing methods (POST, PUT, DELETE), which depends entirely on GET requests never being used to change state in the first place. An application with a GET-based "delete" link, common in older or careless code, is trivially exploitable via CSRF since GET requests can be triggered just by loading an image tag, with no form submission needed at all.
SameSite Cookies as a Complementary Defense
Setting a session cookie's SameSite attribute to Lax or Strict tells the browser not to send that cookie along with cross-site requests in many common scenarios, providing a meaningful additional layer of CSRF defense at the browser level itself, independent of any application-level token. It complements, rather than replaces, the synchronizer token pattern, since SameSite behavior varies somewhat across browsers and request types.
Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnlyAPI Endpoints Need a Different Approach
A stateless API authenticated via a bearer token in an Authorization header, rather than a cookie, is naturally immune to classic CSRF, since the browser does not automatically attach an Authorization header the way it does a cookie. CSRF protection specifically matters for cookie-authenticated, browser-facing endpoints; understanding which authentication model a given endpoint actually uses determines whether CSRF tokens are even the relevant defense for it.
Double Submit Cookie as an Alternative Pattern
Some stateless architectures use a double-submit cookie pattern instead of a session-tied synchronizer token: a random token is set as a cookie and also expected as a request parameter, and the server simply verifies both match. This avoids needing server-side session storage for the token itself, though it provides somewhat weaker guarantees than a session-tied token if an attacker can set cookies on your domain through an unrelated vulnerability.
CSRF Tokens and AJAX Requests
A single-page application making AJAX requests still needs CSRF protection if it is authenticated via cookies rather than a bearer token — the token typically gets embedded in a meta tag on initial page load and attached as a custom header on every subsequent AJAX request, since AJAX requests do not naturally carry a hidden form field the way a traditional form submission does.
fetch('/api/transfer', {
method: 'POST',
headers: { 'X-CSRF-TOKEN': document.querySelector('meta[name="csrf-token"]').content }
});CSRF Tokens Must Be Unpredictable
A CSRF token generated from a predictable source (a sequential counter, a weakly-seeded random function) defeats the entire purpose, since an attacker who can guess or compute the expected token can forge a valid request despite the protection nominally being in place. Generating tokens using a cryptographically secure random source, with sufficient length, is non-negotiable for the protection to actually hold.
Token Rotation and Session Lifecycle
Reusing the exact same CSRF token for a session's entire lifetime, rather than rotating it periodically or after sensitive actions, leaves a slightly longer window during which a leaked token (through a referrer leak or a logging mistake) remains exploitable. Rotating tokens after login and after particularly sensitive actions reduces this exposure window without meaningfully complicating the implementation.
Case Study: The Settings Page With No CSRF Protection
A legacy settings page, predating the rest of the application's CSRF middleware adoption, had been explicitly excluded from CSRF checks years earlier to work around an unrelated bug, and the exclusion was never revisited. An attacker discovered this and crafted a page that silently changed a logged-in victim's account email address to one the attacker controlled, then used a password reset flow against the new email to take over the account entirely. The fix was removing the outdated exclusion and properly fixing the original unrelated bug it had been a workaround for, but the incident prompted a full audit of every CSRF exclusion in the codebase, several of which had similarly outlived their original justification.
A Glossary for This Topic
CSRF: cross-site request forgery, exploiting automatic cookie attachment to forge authenticated requests. Synchronizer token: a unique, session-tied token validated on every state-changing request. SameSite cookie: a cookie attribute restricting when it is sent with cross-site requests. Double submit cookie: a CSRF defense comparing a cookie value against a matching request parameter. State-changing request: any request that modifies data, conventionally not a GET request.
Frequently Asked Questions
Does HTTPS alone prevent CSRF? No, HTTPS protects data in transit but does nothing to stop a forged request originating from a different, legitimate site the victim is also visiting.
Is CSRF still relevant with SameSite cookies widely supported? Yes, SameSite reduces risk but does not eliminate it entirely across all scenarios and browsers; explicit tokens remain the more complete defense.
Do single-page applications need CSRF protection? Yes, if authenticated via cookies; bearer-token authentication in a header is naturally CSRF-resistant instead.
Step-by-Step: Auditing an Application for CSRF Coverage
First, list every endpoint that changes state — create, update, delete operations, and any action with a real side effect. Second, verify each one requires a valid CSRF token, not just the ones obviously using a traditional HTML form. Third, specifically check for any GET-based action that changes state, since these bypass CSRF protection structurally and need converting to a proper POST/DELETE method instead. Fourth, review any CSRF exclusions in the codebase and confirm each one still has a valid, current justification. Fifth, verify AJAX-driven actions correctly attach the token via header, not just traditional form submissions.
A Comparison Table: CSRF Defense Mechanisms
| Mechanism | Strength | Notes |
|---|---|---|
| Synchronizer token | Strong | Standard, session-tied, well understood |
| SameSite cookie | Moderate | Good complementary layer, browser-dependent |
| Double submit cookie | Moderate | No server session storage needed |
| Bearer token auth | Naturally immune | Not vulnerable to classic CSRF at all |
Security Considerations Checklist
Never rely on a CSRF token transmitted or stored in a way that defeats its own purpose, such as embedding it in a URL where it could leak via browser history, referrer headers, or server access logs. Validate tokens server-side using a constant-time comparison where the underlying framework supports it, avoiding subtle timing-based information leakage about how much of the token matched. Ensure CSRF exclusions, when genuinely necessary (certain webhook endpoints authenticated differently), are scoped as narrowly as possible and documented with the specific reason for the exclusion.
Accessibility Considerations
A CSRF token mismatch error page should be clear and actionable for the user encountering it (often after a session has simply expired), explaining what happened and what to do next, structured properly for screen readers rather than presenting a bare, unstyled error with no accessible context.
How This Plays Out at Different Scales
A small application can rely on a framework's default CSRF middleware with minimal customization needed. A growing application with a mix of traditional forms and AJAX-driven interfaces needs the explicit token-in-header pattern described earlier applied consistently across both. A large, complex application integrating multiple authentication models (cookie sessions alongside API tokens) needs careful, deliberate review of which endpoints need CSRF protection and which are naturally exempt through token-based authentication instead.
What to Do When You Inherit an Application With Inconsistent CSRF Coverage
Inheriting an application where some endpoints have CSRF protection and others do not, with no clear pattern explaining the difference, needs a full audit rather than assuming the existing coverage is intentional and correct. Follow the step-by-step audit process described earlier exactly, treating every unexplained exclusion as a bug until proven otherwise with a specific, current, valid justification, since the case study above shows exactly how an old, forgotten exclusion becomes a real exploited vulnerability years later.
Final Checklist Before Trusting Your CSRF Protection
Every state-changing endpoint requires a valid CSRF token, with no unexplained exceptions. No state-changing action is reachable via a GET request. AJAX-driven actions correctly attach the token via a custom header, verified by an actual test, not just visual inspection of the code. SameSite cookie attributes are set as a complementary defense layer. Any CSRF exclusion that does exist is documented with its specific, current justification.
Closing Thought, Revisited
CSRF protection is easy to treat as a solved problem once a framework's default middleware is in place, but the case study above shows how a single forgotten exclusion, justified once for reasons long since irrelevant, can undo that protection entirely for one specific endpoint. Periodically re-auditing exclusions, not just trusting that the framework default covers everything by itself, is what keeps this protection genuinely complete rather than complete in theory only.
CSRF in Multi-Step Forms and Wizards
A multi-step form spanning several page loads, each potentially issuing a fresh CSRF token if not handled carefully, can break if an earlier step's token becomes invalid by the time a later step submits. Keeping a single token valid across the entire flow, tied to the overall session rather than regenerated per step, avoids users hitting a confusing token-mismatch error partway through a long form simply because they took a normal amount of time to complete it.
Testing CSRF Protection Automatically
A test asserting that a state-changing request without a valid token is rejected, and that the same request with a valid token succeeds, verifies the protection is actually wired up correctly rather than just assumed to be working because the framework's default middleware is technically present. This is worth a dedicated, explicit test specifically because CSRF bugs tend to be invisible during normal manual testing, where a developer's own browser session naturally includes a valid token without them ever having to think about it.
CSRF and Third-Party Payment Redirects
A checkout flow redirecting to a third-party payment provider and back can complicate token handling if the returning request needs to trigger a state change on your own site, since the user's session and token state must still be valid and correctly recognized after the round trip through an external domain. Designing the return flow to re-validate the user's session and require a fresh token for any subsequent state-changing action, rather than assuming the redirect alone implies a trusted, authenticated continuation, avoids a subtle gap an attacker could otherwise exploit around the redirect boundary.
Mobile App Backends and CSRF
A backend serving a native mobile app, authenticated via a bearer token rather than a browser cookie, does not need traditional CSRF protection for that mobile traffic, since the browser-cookie-based attack vector simply does not apply to a non-browser client. A backend serving both a web frontend and a mobile app needs to apply CSRF protection selectively, to the cookie-authenticated web traffic only, without mistakenly requiring a CSRF token from the mobile client that never set a cookie at all.
CSRF Tokens and Caching Interactions
A page containing a CSRF token embedded in its HTML cannot be cached and served identically to every visitor, since each visitor needs their own session-tied token, not a previous visitor's cached one. Excluding pages containing forms from full-page caching, or fetching the token via a separate, uncached endpoint after the cached page loads, avoids serving a stale or mismatched token that would cause every subsequent form submission to fail validation.
Communicating a CSRF Failure Clearly to Users
A generic, unexplained error after a CSRF token mismatch (often simply caused by an expired session after the user left a tab open for a long time) frustrates users who have no idea what went wrong or what to do about it. Detecting this specific failure case and showing a clear, friendly message — "your session expired, please try again" — rather than a raw 419 status page, turns a confusing dead end into a recoverable, well-understood moment for the user.
CSRF Considerations for Embedded Widgets
An embeddable widget your application provides for other sites to include (a comment widget, a booking form) that submits back to your domain needs careful CSRF handling, since the embedding context is, by definition, a different origin than your own. Designing the widget's submission flow with its own appropriately-scoped token issued specifically for that embedded context, rather than assuming the same protection used for your main site's own forms applies unchanged, avoids leaving this specific, easy-to-overlook integration point unprotected.
