Use synchronizer tokens when the application is session-based and server state is already part of the design. Use double-submit cookies only when the system is truly stateless and the cookie and header handling is tightly controlled. The wrong choice usually appears when teams try to optimise for simplicity before they stabilise the authentication model.
How to choose the CSRF pattern based on your session model
Synchronizer tokens fit the classic stateful web application because the server already maintains a session and can tie each anti-CSRF value to that server-side state. Double-submit cookies only become attractive when you are genuinely building a stateless API or edge layer and cannot rely on server-side token storage. The choice is less about elegance than about whether your authentication and request validation model can actually support the control.
That distinction matters because csrf protection is not just a checkbox, it is a binding mechanism between the browser, the authenticated session, and the request that changes state. A stateful app can verify a server-issued token against the session. A stateless design must instead ensure the cookie and the request header are both under the same trust boundary and cannot be replayed or forged independently.
For teams modernising older applications, the practical mistake is to adopt double-submit cookies because they seem lighter weight, then later discover that load balancers, subdomains, token reuse, or inconsistent cookie scope have weakened the guarantee. The simpler pattern is only simpler when the surrounding architecture already enforces the needed invariants.
Where each approach is strong, and where it breaks down
Synchronizer tokens are strongest when the application server can generate, store, and validate a per-session or per-request value without making the client responsible for proving anything other than possession of the browser session. That makes the control robust against token reuse across sessions and easier to reason about when the app already has an authentication server, session store, or server-rendered workflow.
Double-submit cookies can work, but the security property depends on careful cookie handling. The cookie must be inaccessible to attacker-controlled scripts where possible, scoped correctly, and compared against a header or form field that an attacker cannot set from a cross-site request. If the cookie is shared too broadly, or the application accepts the same token too loosely, the control becomes fragile. For implementation guidance around issuing and handling bearer-style credentials safely, API Key Management Guide is a useful adjacent reference on scope, rotation, and revocation discipline.
Both patterns also depend on what else the browser can do. If a site has XSS, CSRF defences are no longer the main line of defence because an injected script can often read, replay, or manufacture the client-side inputs the control depends on. That is why the anti-CSRF decision should be made alongside session handling, cookie attributes, and frontend hardening rather than in isolation.
What practitioners should verify before standardising on one pattern
Before choosing a pattern, verify whether your application is truly stateful, truly stateless, or somewhere in between. Hybrid systems are common, and the wrong assumption about where state lives creates brittle defences. If the app already maintains a server session, synchronizer tokens usually give the clearest assurance. If the app is intentionally stateless, confirm that the cookie and request path can be constrained tightly enough to make double-submit meaningful.
You should also verify that the token is checked on every state-changing action, not only on a few high-risk endpoints. Anti-CSRF controls fail most often when teams protect the obvious flows and miss secondary actions such as profile changes, payment setup, email changes, or delegated admin operations. For broader identity and token hygiene, Ultimate Guide to NHIs, what are Non-Human Identities helps connect the same access-control logic to service and machine credentials where request trust also matters.
Finally, verify that your cookie attributes, SameSite behaviour, and domain scoping match the chosen model. Many teams overestimate what SameSite alone provides, or they assume a browser default will rescue a weak design. The control should be explicit, testable, and measurable in the same environments where authentication actually runs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | CSRF defenses are tied to browser auth flows that use OAuth/OIDC redirects and state checks. |
| Recommendation — Use state and callback validation to bind browser auth responses to the initiating session. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | CSRF token choice depends on how authenticated user sessions are established and maintained. |
| AC-3 — Access Enforcement | Anti-CSRF controls help enforce that only intended authenticated actions are executed. | |
| Recommendation — Tie request validation to the authenticated session and verify identity on each state change. Enforce request checks before allowing state-changing actions. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | CSRF protection is part of securing authenticated browser sessions against unauthorized actions. |
| Recommendation — Implement request validation controls that protect authenticated sessions from forged actions. | ||
Practitioner Guidance
What to prioritise: Start from the session architecture, not from the anti-CSRF pattern. If the application already has server-side session state, favour synchronizer tokens and keep the validation server-controlled; if it is deliberately stateless, only then consider double-submit cookies.
Decision rule: If you cannot clearly explain where the browser token is generated, where it is validated, and what prevents cross-site replay, do not treat the design as settled. The pattern is only defensible when those answers are stable across all state-changing requests.
Common mistake: Teams often choose double-submit cookies to reduce implementation work, then compensate later with ad hoc exceptions, broad cookie scope, or endpoint-specific checks. That usually creates a weaker and harder-to-review control than a straightforward server-side synchronizer token.
Practitioner takeaway: The best CSRF control is the one that matches your authentication model without relying on architectural assumptions you have not already made true.
Related resources from NHI Mgmt Group
- How should teams harden Express.js applications that rely on double-submit cookies for CSRF protection?
- What breaks when an AI workflow platform uses cookies for refresh tokens without CSRF protection?
- What are the implications of using OAuth tokens in third-party integrations?
- What makes OAuth tokens risky in NHI environments?