CSRF Token
What is CSRF Token?
CSRF TokenUnpredictable, per-session value embedded in forms or headers so the server can confirm that state-changing requests originate from its own pages.
A CSRF token is the canonical defence against Cross-Site Request Forgery. The server generates a random value, binds it to the user's session, and embeds it in HTML forms or sends it via a custom header. On each state-changing request, the server compares the submitted token to the expected value and rejects mismatches. Variations include synchronizer token pattern (server-side state), double-submit cookies (stateless), and the OWASP HMAC pattern. Modern apps should combine CSRF tokens with SameSite=Lax or Strict cookies, custom request headers verified for the Origin/Referer, and strict CORS configuration. Bearer-token APIs called only from JS do not need a CSRF token but still need anti-replay controls.
● Examples
- 01
Hidden <input type="hidden" name="csrf" value="a8f1..."> field in a form.
- 02
X-CSRF-Token header validated server-side against a per-session secret.
● Frequently asked questions
What is CSRF Token?
Unpredictable, per-session value embedded in forms or headers so the server can confirm that state-changing requests originate from its own pages. It belongs to the Identity & Access category of cybersecurity.
What does CSRF Token mean?
Unpredictable, per-session value embedded in forms or headers so the server can confirm that state-changing requests originate from its own pages.
How does CSRF Token work?
A CSRF token is the canonical defence against Cross-Site Request Forgery. The server generates a random value, binds it to the user's session, and embeds it in HTML forms or sends it via a custom header. On each state-changing request, the server compares the submitted token to the expected value and rejects mismatches. Variations include synchronizer token pattern (server-side state), double-submit cookies (stateless), and the OWASP HMAC pattern. Modern apps should combine CSRF tokens with SameSite=Lax or Strict cookies, custom request headers verified for the Origin/Referer, and strict CORS configuration. Bearer-token APIs called only from JS do not need a CSRF token but still need anti-replay controls.
How do you defend against CSRF Token?
Defences for CSRF Token typically combine technical controls and operational practices, as detailed in the full definition above.
● Related terms
- attacks№ 239
Cross-Site Request Forgery (CSRF)
A web attack that forces an authenticated user's browser to send unwanted requests to a vulnerable site, causing state-changing actions without consent.
- appsec№ 961
SameSite Cookie
A cookie attribute that controls whether browsers attach the cookie on cross-site requests, with values Strict, Lax and None, used primarily to mitigate CSRF.
- identity-access№ 1020
Session Token
Opaque identifier issued after authentication that the client returns with each request, letting the server look up the user's session state.
- identity-access№ 1018
Session Management
The set of controls that issue, maintain, refresh, and revoke an authenticated session, binding a user's identity to subsequent requests until logout or expiration.
- appsec№ 983
Secure Cookie Flag
A cookie attribute that tells the browser to send the cookie only over HTTPS, preventing exposure in cleartext on the network.
- appsec№ 223
CORS (Cross-Origin Resource Sharing)
A browser-enforced mechanism that lets a server selectively relax the Same-Origin Policy so that JavaScript on one origin can read responses from another.