CSRF token

The synchronizer token pattern is the stateful form: the server generates a large unpredictable value with a cryptographically secure random number generator, stores it in the server-side session and embeds it in every form as a hidden field or exposes it to JavaScript through a meta tag. On every unsafe request (POST, PUT, PATCH, DELETE) the server compares the submitted value with the stored one using a constant-time comparison and rejects the request on mismatch or absence. Per-request tokens shorten the window in which a leaked token is useful, and OWASP rates them as more secure, but they break the back button and multiple open tabs, so per-session tokens are the common default.

Stateless applications use the double-submit cookie pattern: the token is sent both as a cookie and as a request parameter or header, and the server checks that the two match. The naive version is weak, because an attacker who can write cookies for the domain, for example from a compromised or vulnerable subdomain or through a man-in-the-middle on plain HTTP, can plant a matching pair. OWASP therefore recommends the signed double-submit variant, where the token is an HMAC, keyed with a server secret, over a session-bound value that changes at each login and a random value, so a planted cookie fails verification. Cookie name prefixes such as __Host- further prevent subdomains from overwriting the cookie.

Where the token travels matters. It must never appear in a URL, since URLs leak through Referer headers, logs and browser history. Single-page applications typically read it from a cookie or an endpoint and send it in a custom header such as X-CSRF-Token or X-XSRF-TOKEN (the convention Angular's HttpClient uses). Frameworks mask the token on each render, XOR-ing it with a fresh random pad as Django and Rails do, so that the value in an HTTPS-compressed response cannot be recovered with a BREACH-style length side channel.

A CSRF token is not an authentication secret and offers no protection against XSS: any script running in the same origin can read it from the DOM. It also does nothing for requests authenticated with a bearer token in an Authorization header, which browsers do not attach automatically, so APIs that do not use cookies usually do not need one. Regenerating the token when the user logs in avoids session fixation-style reuse of a token obtained before authentication.