CSRF: Double Submit Cookies for Stateless Backends

WHY IT EXISTS Traditional CSRF protection, the Synchronizer Token Pattern, requires the server to store a token in the user's session. In modern stateless architectures, like APIs serving a Single Page App, there is often no server-side session. Double Submit Cookies provide CSRF protection without needing any server-side storage.

THE MENTAL MODEL Think of it as a two-part key. The server gives the user a key (the cookie) that their browser carries automatically. To prove they are the legitimate user making a request, they must also show a copy of that key in their hand (the request header). An attacker can trick the browser into carrying the key, but they can't see inside the browser's keychain to make a copy to show in their hand. The server just checks if the two parts match.

HOW IT WORKS Upon user login or initial page load, the server generates a cryptographically random value. It sets this value in a cookie sent to the client. Crucially, this cookie is configured to be accessible to JavaScript (HttpOnly=false). For every subsequent state-changing request (POST, PUT, DELETE), the client-side JavaScript reads the token from the cookie and includes it in a custom HTTP header, like X-CSRF-Token. The server receives the request, extracts the token from the header, extracts the token from the cookie, and simply compares them. If they match, the request is valid. If they don't, it's rejected.

WHEN TO USE IT This pattern is ideal for stateless applications. It's common in Single Page Applications (SPAs) talking to a REST or GraphQL API, where you want to avoid the complexity and overhead of maintaining session state on the server just for CSRF tokens.

WHEN NOT TO USE IT The main weakness is its reliance on the Same-Origin Policy. If your application has any Cross-Site Scripting (XSS) vulnerabilities, an attacker can use XSS to read the cookie, get the token, and forge a valid request, completely bypassing this protection. If you have a stateful application, the Synchronizer Token Pattern is generally more secure.

ONE CANONICAL EXAMPLE A user logs into app.com. The server responds with a session cookie and a csrf_token cookie with HttpOnly=false and SameSite=Strict. A React frontend reads the csrf_token cookie value using JavaScript. When the user tries to delete their account, the frontend makes a DELETE /api/account request, including the token in an X-CSRF-Token header. The backend API receives the request, reads the X-CSRF-Token header, reads the csrf_token cookie, and verifies they are identical before proceeding.