CSRF: requests your users never meant to send

Definitions follow OWASP and CWE-352.

1. The victim is signed in to your site. Their browser holds a session cookie for it.
2. The victim visits another page. A malicious site, a forum post or an email the attacker controls.
3. That page makes the browser send a request to your site. Through a form that submits itself, an image address or a script.
4. The browser attaches the session cookie. Your site sees an authenticated request and carries it out.

The attacker never sees the response; CSRF is about making the victim act, not about reading. It works only on actions that change something and can be triggered by a request the attacker can predict in full.

Imagine a site where a signed-in user can change the email address on their account by submitting a form with one field. The form has no token, and the session cookie has no SameSite attribute.

An attacker builds a page with an identical hidden form that sets the email to an address they control, and makes it submit itself when the page loads. A user who is signed in and opens that page sends the change without seeing anything. The attacker then asks for a password reset, which goes to the new address, and takes over the account. A token in the real form, unknown to the attacker, would have made the forged submission fail.

Cross-site scripting puts attacker script inside your site, where it can read pages and act as the user. CSRF works from outside: it can make the user's browser send a request, but it cannot read anything back.

The two interact. A site with an XSS flaw loses most CSRF protection, because script on the site can read the token the same way the page does. Fixing XSS is part of keeping CSRF defences meaningful.

1. Use anti-forgery tokens. A secret value tied to the session (a CSRF token), sent in every form and checked on the server; the OWASP CSRF Prevention Cheat Sheet describes the patterns.
2. Set SameSite on session cookies. With SameSite=Lax or Strict, browsers stop sending the cookie on most cross-site requests; see Set-Cookie on MDN.
3. Never change state with GET. Actions that change data should require a method a link or image cannot trigger.
4. Check Origin or Referer on sensitive actions. As an extra layer, not the only one.
5. Ask again for the most sensitive actions. Re-entering a password or a second factor defeats a forged request.

Very little on its own. A forged request has the right method, the right parameters and the user's real cookies; nothing in its content looks like an attack. A filter can check headers such as Origin on chosen paths, but the decision about which requests need proof of intent belongs to the application.

That is why CSRF sits in broken access control: the server accepted an action without checking that the user meant it.