CSRF tricks a logged-in user's browser into sending a request they didn't intend, to a site where they're authenticated. Because browsers automatically attach session cookies, the site sees a valid, authenticated request and performs the action with the victim's privileges - the app can't distinguish a genuine action from a forged one. No password is stolen and no data is read; the attacker just causes a state-changing side effect (password change, email update, funds transfer). The fixes: (1) an anti-CSRF token - a secret, unpredictable per-session value required on every state-changing request, which the attacker's cross-site page can't read; and (2) the SameSite cookie attribute, telling the browser not to send the session cookie cross-site. Use both, plus proper HTTP methods and re-auth for sensitive actions. Not the same as XSS - detail below.
// 01 What CSRF is
Cross-site request forgery (CSRF) is a web vulnerability that tricks a logged-in user's browser into sending a request the user did not intend, to a site where they are authenticated. The mechanism rests on one fact about browsers: they automatically attach a user's session cookies to any request made to a site. So an attacker who can cause the victim's browser to make a request to that site - for example by getting them to visit a malicious page - can have the request carried out with the victim's privileges. Crucially, the application cannot tell the difference between a genuine action the user chose to perform and a forged one initiated by the attacker's page. CSRF therefore lets an attacker perform state-changing actions - changing account details, updating an email, making a transaction - as the victim, without ever stealing their password. It's a failure of intent verification, not of authentication.
// 02 How a CSRF attack works
The attack has a simple, reliable choreography:
Victim is logged in
The victim already has a valid session with the target site - their browser holds the session cookie.
Attacker crafts a request
A page or email with a hidden request to the target - an auto-submitting form, or an image tag pointing at an action URL.
Victim loads it
Lured into opening it, the victim's browser fires the request and automatically includes their session cookies.
Site performs the action
The target sees an authenticated, valid-looking request and carries it out - a password change, email update, or transfer.
The attacker never sees the response and doesn't need to read any data; they simply cause a side effect to happen with the victim's authority. The whole attack relies on the site trusting that any request carrying a valid session cookie was intentional - which is exactly the assumption CSRF breaks.
// 03 How to prevent CSRF
Anti-CSRF token (the primary defence). The server issues a secret, unpredictable value tied to the user's session, embeds it in forms, and requires it on every state-changing request - rejecting any request that lacks the correct token. Because the attacker's cross-site page cannot read that token (the same-origin policy stops it), it cannot forge a valid request. SameSite cookies (the complementary defence). The SameSite attribute tells the browser not to send the session cookie on cross-site requests, cutting off the very mechanism CSRF depends on. Good practice combines both, ensures state-changing actions use appropriate HTTP methods (POST/PUT/DELETE, not a plain GET link), and may re-authenticate the user for especially sensitive actions. And critically: enable your framework's built-in CSRF protection rather than hand-rolling it - every major web framework ships a tested implementation. One caveat: CSRF defences assume the site is free of XSS, because script running on the site can simply read the token (see below).
// 04 CSRF vs XSS - not the same thing
These two are constantly confused. Cross-site scripting (XSS) is about injecting and running malicious script within the trusted site - it gives the attacker code execution in the victim's browser session, so it can read data, steal tokens, and do almost anything the user can. CSRF runs no code on the target site at all; it merely causes the victim's browser to send a request to a site where they're already logged in, exploiting the automatic inclusion of cookies. XSS is generally more powerful because it runs inside the trusted origin - and notably, an XSS flaw can defeat CSRF defences by reading the anti-CSRF token. The defences differ too: CSRF is countered by tokens and SameSite cookies; XSS by output encoding and a content security policy. In a web application penetration test we check for both, and specifically confirm that state-changing endpoints validate a token and can't be driven cross-site - part of the OWASP Top 10 coverage every test should include.
// 05 Frequently asked questions
What is cross-site request forgery?
A web vulnerability that tricks a logged-in user's browser into sending a request they didn't intend, to a site where they're authenticated. Because browsers automatically attach session cookies, an attacker who causes the victim's browser to make that request has it carried out with the victim's privileges - and the app can't tell a forged action from a genuine one. It lets an attacker perform state-changing actions as the victim without ever stealing their password.
How does a CSRF attack work?
The victim is already logged in, so their browser holds a valid session. The attacker crafts a page or email with a hidden request to the target - an auto-submitting form or an image tag pointing at an action URL - and lures the victim into loading it. The browser makes the request, automatically including the session cookies, so the site sees an authenticated request and performs the action. The attacker never sees the response; they just cause a side effect like a password change or funds transfer with the victim's authority.
How do you prevent CSRF?
The primary defence is an anti-CSRF token: a secret, unpredictable value tied to the session, embedded in forms and required on every state-changing request, so the attacker's cross-site page (which can't read it) can't forge a valid request. A complementary defence is the SameSite cookie attribute, which stops the browser sending the session cookie cross-site. Combine both, use appropriate HTTP methods for state changes, re-authenticate for sensitive actions, and enable framework-provided protection rather than hand-rolling it.
What's the difference between CSRF and XSS?
XSS injects and runs malicious script within the trusted site, giving code execution in the victim's session - it can read data and steal tokens. CSRF runs no code on the target; it just causes the victim's browser to send a request to a site where they're logged in, exploiting automatic cookie inclusion. XSS is generally more powerful because it runs inside the trusted origin, and can even defeat CSRF defences by reading the token. CSRF is countered by tokens and SameSite cookies; XSS by output encoding and CSP.
// 06 Related reading
- XSS explained — the vulnerability CSRF is most often confused with.
- OWASP Top 10 in real engagements and session management testing.
- Web application penetration testing — where CSRF is tested.