A CSRF attack forces a victim’s browser to fire off a request it never meant to send. It rides on the session cookie already stored for the target site. No password gets stolen and no code runs in the browser. The server just sees a cookie it trusts, attached to a request the real user never authorised. It acts on that request anyway.
That single mechanism, cookies attached automatically, is the entire vulnerability. Everything else in this guide, the conditions, the exploits, the fixes, follows from that one fact.
The Mechanics of a CSRF Attack
OWASP defines CSRF as forcing an authenticated user to execute unwanted actions on a web application. Break that down into what actually crosses the wire:
- The victim is logged into a target site, so their browser holds a valid session cookie for it.
- The victim loads attacker-controlled content, a page, an email, an ad, that contains a request aimed at the target site.
- That request reaches the target domain. The browser attaches the stored session cookie automatically, because that is what browsers do for every request to a matching domain.
- A vulnerable server then checks the cookie and finds it valid. It processes the request as if the real user submitted it on purpose.
PortSwigger’s research team narrows this down to three preconditions. All three have to hold: a state-changing action worth targeting, a session that depends purely on cookies, and request parameters an attacker can predict. Remove any one and the attack stops working.
Two Documented CSRF Exploits
This is not a theoretical bug class.
Router DNS hijack, 2008. Attackers sent an email disguised as a message from the e-greeting site Gusanito.com, targeting customers of a Mexican bank. The email held a hidden image tag. Opening it sent a forged request straight to the victim’s home router, silently changing its DNS settings. Every subsequent visit to the bank’s real address then routed through infrastructure the attacker controlled. Symantec and researchers from Indiana University documented the case as the first “drive-by pharming” attack observed in the wild.
uTorrent configuration interface, 2008. OWASP’s own community write-up cites a CSRF flaw in uTorrent’s web-based settings page. Attackers exploited it at scale to install unwanted software on victims’ machines, again without phishing a single credential.
Neither case needed the attacker to guess a password or defeat encryption. Both relied on a device or application treating a cookie as sufficient proof that a request was legitimate. In the router’s case, a trusted network position played the same role. That is the pattern worth remembering: a CSRF attack rarely raises an obvious red flag. From the server’s point of view, the request looks exactly like one the real user would send.
Testing Whether an Endpoint Is Vulnerable
A quick manual check, useful for developers auditing their own application:
- Identify a state-changing request, one that updates an email address, password, or setting.
- Build a minimal standalone HTML page with a form or auto-submitting request pointed at that same endpoint, using realistic parameter values.
- Remove any CSRF token field from your copy of the request.
- Load that page in a browser that is currently logged into the target application, and see whether the action completes.
If it does, the endpoint is trusting the session cookie alone, exactly the gap a CSRF attack needs.
CSRF and XSS Are Not the Same Bug
OWASP is explicit on this point because the two get conflated constantly. Cross-site scripting gets attacker code to execute inside the victim’s browser. It sits in the same family of OWASP-tracked flaws as SQL injection. That vulnerability abuses a database query rather than a cookie. A CSRF attack runs no code at all. It forges a request and lets the browser’s own cookie handling do the rest.
| CSRF | XSS | |
|---|---|---|
| Attacker code executes in victim’s browser | No | Yes |
| Root cause | Cookies sent automatically, no other proof of intent | Unsafe rendering of untrusted input |
| Core fix | Per-request tokens, SameSite cookies | Output encoding, CSP |
Defences That Actually Work
OWASP’s Cross-Site Request Forgery Prevention Cheat Sheet lays out the layers worth implementing.
Synchronizer Tokens
A token unique to the session, secret, and unpredictable gets embedded in every state-changing form or request and validated server-side. Forged requests from another origin have no way to obtain that token. They fail even with a genuine session cookie attached.
Signed Double-Submit Cookies
A token is sent in both a cookie and a request parameter, then compared. OWASP recommends signing it with a server-side secret (HMAC). The unsigned, naive version can be beaten by an attacker who manages to plant a cookie from a shared parent domain.
SameSite Cookies: What Each Value Actually Does
| Value | Behaviour |
|---|---|
| Strict | Cookie never sent on any cross-site request |
| Lax (Chrome default since 2021) | Cookie blocked on cross-site POST/PUT/DELETE, still sent on cross-site GET and top-level navigation |
| None | Cookie sent on all requests; requires the Secure flag |
Lax closes off a large share of forged requests by default, but OWASP is direct about the gap: it is defence in depth, not a substitute for a real CSRF defence. Any state-changing action still reachable through GET slips past Lax entirely. The SameSite scope also covers the registrable domain, not the origin. A subdomain you do not control can still undermine it. That is exactly why OWASP tells developers not to let GET requests change state.
Login CSRF: The Case Before Authentication
An attacker can forge a request that logs a victim into the attacker’s own account, before any session token exists to protect against it. Anything the victim enters afterwards, such as stored card details, gets tied to an account the attacker holds. OWASP’s fix is a pre-session token, issued and validated as part of the login request itself.
Frequently Asked Questions
Does HTTPS prevent a CSRF attack?
No. OWASP specifically lists HTTPS among the measures that do not stop CSRF. It only protects data in transit and does nothing to verify that a request was actually intended.
Is a referrer header check a reliable defence?
Not on its own. OWASP groups referrer checking with secret cookies and POST-only rules. All three help, but none should be relied on alone, since the header can be absent from legitimate requests too.
Can a REST API be hit by a CSRF attack?
Yes, if it authenticates purely through cookies and accepts ordinary requests. APIs that require a custom header carrying a bearer token are naturally more resistant. Browsers do not attach custom headers to cross-site requests on their own.
What is login CSRF, in one sentence?
It is a forged request that logs a victim into the attacker’s account rather than stealing the victim’s own session. It works because no session token protects an unauthenticated login form.
Why doesn’t SameSite=Lax fully solve the problem?
It only blocks unsafe methods like POST. A vulnerable action still reachable via GET, or a subdomain outside your control, both slip past it.
Who should worry about CSRF: developers, testers, or both?
Both. Developers need to implement the token and cookie defences correctly on every state-changing endpoint. Testers and penetration testers need to check for the gaps developers miss. That matters most on older endpoints added before a framework’s built-in CSRF protection existed.