Overview
The classic defense against CSRF is the anti-CSRF token — a secret, unpredictable value the application requires with state-changing requests to prove the request came from its own pages. This lesson explains CSRF tokens.
Learning objectives
- Define an anti-CSRF token and how it works.
- Explain why it defeats CSRF.
- Describe correct token handling.
Core concept
An anti-CSRF token is a secret, per-session (or per-request) unpredictable value that the server embeds in its own forms/pages and requires to be returned with state-changing requests. Because an attacker's cross-site page cannot read the token (it is not sent automatically like a cookie, and cross-origin reads are blocked by the browser), a forged request will lack a valid token and be rejected. The token proves the request originated from a page the application itself served — establishing intent that the cookie alone cannot.
How it works
The server generates a token tied to the user's session and includes it in its forms (e.g. a hidden field) or makes it available to its own JavaScript. When the user performs a state-changing action from a legitimate page, the token accompanies the request and the server validates it. An attacker forging a request from another site cannot obtain the correct token — the browser will still send the cookie automatically, but not the token, which the attacker cannot read due to the same-origin policy. The missing/invalid token causes rejection, defeating the CSRF. This is the synchronizer token pattern.
Practical example
A funds-transfer form served by the bank includes a hidden anti-CSRF token unique to the user's session. When the user submits, the token is sent and validated — the action proceeds. An attacker's malicious page can trigger a request to the transfer endpoint (and the browser attaches the session cookie), but it cannot include a valid token because it cannot read the bank's page. The server sees a missing/invalid token and rejects the forged transfer. The token supplied the proof of intent that the cookie could not.
Cybersecurity relevance
Anti-CSRF tokens are a long-standing, effective defense and are built into most web frameworks. Correct handling matters: tokens must be unpredictable, tied to the session, validated on every state-changing request, and not leaked (e.g. via URLs or to other origins). Many frameworks provide CSRF protection that should be enabled rather than hand-rolled. Testers check whether state-changing endpoints require and correctly validate tokens; defenders ensure tokens are present, unpredictable, and enforced. Tokens are often combined with SameSite cookies (next lesson) for layered defense.
Common mistakes
- Not validating the token on the server for every state-changing request.
- Using predictable or leakable tokens (e.g. exposing them in URLs shared cross-site).
- Hand-rolling CSRF protection instead of enabling the framework's tested mechanism.
Key takeaways
- An anti-CSRF token is a secret, unpredictable value required with state-changing requests to prove they came from the application's own pages.
- It defeats CSRF because an attacker's cross-site page cannot read the token (unlike the auto-sent cookie), so forged requests lack it and are rejected.
- Tokens must be unpredictable, session-bound, validated on every state-changing request, and not leaked; prefer the framework's built-in protection.
Check your understanding
- Why can an attacker's cross-site page not obtain a valid anti-CSRF token?
- What must the server do with the CSRF token on every state-changing request for the defense to work?