What It Actually Means
The mechanism relies on something browsers do helpfully: they attach your cookies for a site to any request going to that site, regardless of which page triggered it. So a page on an attacker’s site can quietly send a request to your application, and your application receives it complete with the user’s valid session.
From the application’s point of view the request is genuine. The right user, a valid session, a well-formed instruction. The only thing wrong is that the user never meant it.
What It Is Used For
CSRF changes things rather than reading them, which shapes what it is worth to an attacker.
Typical targets are changing the email address on an account, which then enables a password reset the attacker controls; adding a user; transferring something; changing a delivery address; altering a permission. Anything that takes effect through a single submitted action.
The severity depends entirely on what your application lets a user do in one step. Systems where meaningful actions require several deliberate steps are naturally more resistant, which is a design property rather than a security feature.
The Defence
A token. The server issues a value tied to the user’s session, embeds it in the form, and rejects any submission that arrives without it. An attacker’s page cannot read that value, because browsers prevent one site reading another’s content, so it cannot forge a valid request.
Every current framework includes this and applies it by default. SameSite cookie settings, now the browser default, block a large share of the remaining cases independently.
The result is that CSRF should be a solved problem, and where it appears it is usually because someone disabled the protection to fix something else. The common trigger is an integration or a form that stopped working, protection being switched off to get it moving, and nobody returning to do it properly.
What To Ask
- Is CSRF protection on, and has it been disabled anywhere? The exceptions are the answer. Ask where and why.
- Are our cookies SameSite? A one-line setting that removes most of the exposure.
- Do state-changing actions ever happen on a GET request? Anything that changes data should be a POST. Change-by-link is the pattern that makes this easy to exploit.
- Do sensitive changes require re-entering a password? Email address and payment details should. It defeats this entirely for the actions that matter most.
How It Differs From XSS
The two are frequently confused and the difference decides the remedy.
Cross-site scripting runs the attacker’s code inside your page, so they can read what is there. CSRF cannot read anything. It can only cause an action to happen blindly.
That makes XSS strictly more dangerous, and it means XSS defeats CSRF protection completely: code running inside your page can simply read the token. So the two are not independent defences. Fixing CSRF while leaving XSS open protects nothing.
More terms are in the glossary.
