How CSRF Works
IntermediateCross-site request forgery (CSRF) tricks a logged-in user browser into sending an unwanted authenticated request to a site they trust. Because browsers automatically attach cookies to requests for a domain, a malicious page can make the victim browser perform actions — transfer money, change an email — on a site where the victim has an active session, without the victim intending it. The defences are CSRF tokens (a secret the attacker cannot know) and SameSite cookies (which stop cookies riding on cross-site requests).
Think of a signed blank check in your pocket
Your session cookie is like a signed blank check the bank honours from whoever presents it. Normally only you use it. CSRF is a con artist handing you a form to sign that secretly instructs your bank to pay them — and because your check (cookie) is automatically attached, the bank obeys. A CSRF token is a secret passphrase the bank also requires that only the real form includes; the con artist form lacks it, so the bank refuses.
Step by Step
Key Concepts
Ambient Authority
The browser automatically attaching cookies to every request for a domain, regardless of which site triggered it. This is exactly what CSRF abuses to make authenticated requests the user did not intend.
CSRF Token
A secret, unpredictable value the server generates and embeds in legitimate forms/requests, then verifies on submission. An attacker cannot guess it, so forged cross-site requests fail the check.
SameSite Cookies
A cookie attribute (Lax or Strict) that tells the browser not to send the cookie on cross-site requests. It blocks most CSRF at the source and is now a browser default (Lax).
CSRF vs XSS
CSRF makes the browser send forged requests using existing credentials but cannot read responses; XSS runs attacker script in the page and can read data. They are different attacks with different defences.
Key Facts
- CSRF exploits that browsers automatically send cookies — the attacker never sees the session, they just cause the victim browser to use it.
- Token-based APIs that authenticate with an Authorization header (not cookies) are largely immune to classic CSRF, since the token is not sent automatically.
- SameSite=Lax is now a common browser default, which mitigates many CSRF attacks — but explicit CSRF tokens remain the robust defence for cookie-based sessions.
Real-World Applications
Protecting a form-based web app
A traditional server-rendered app that uses session cookies includes a per-session CSRF token in every state-changing form; the server rejects any POST lacking the correct token, blocking forged requests.
Choosing token auth for APIs
A single-page app that authenticates with a bearer token in the Authorization header avoids automatic cookie attachment, sidestepping classic CSRF — one reason token auth is popular for APIs.
Frequently Asked Questions
What is cross-site request forgery (CSRF)?
CSRF is an attack that tricks a logged-in user browser into sending an unwanted authenticated request to a site the user trusts. Because browsers automatically attach cookies to requests for a domain, a malicious page can cause the victim browser to perform actions — like changing an email or transferring money — on a site where the victim has an active session, without the victim intending it. The server sees a valid session cookie and treats the forged request as genuine.
How do you prevent CSRF?
The two main defences are CSRF tokens and SameSite cookies. A CSRF token is a secret, unpredictable value the server issues and embeds in legitimate forms or requests, then verifies on submission; forged cross-site requests lack it and are rejected. SameSite cookies (Lax or Strict) tell the browser not to send the session cookie on cross-site requests, blocking the attack at the source. For APIs, authenticating with a bearer token in a header rather than a cookie also avoids classic CSRF.
What is the difference between CSRF and XSS?
They are distinct attacks. CSRF forces a victim browser to send forged authenticated requests using credentials the browser already has (cookies), but the attacker cannot read the responses. XSS injects and runs malicious script inside a trusted page, which can read data, steal tokens, and act as the user. They require different defences — CSRF tokens and SameSite cookies for CSRF, output encoding and CSP for XSS.
Are token-based APIs vulnerable to CSRF?
Generally much less so than cookie-based sessions. Classic CSRF works because browsers send cookies automatically. If an API authenticates with a token sent in the Authorization header (as many single-page apps do), that token is not attached automatically by the browser, so a malicious cross-site page cannot include it in a forged request. This is one reason header-based token authentication is favoured for APIs — though cookies used for auth still require CSRF protection.