CSRF exploits something the browser does to be helpful. When your bank sets a session cookie, the browser attaches it to every subsequent request to the bank, automatically, no matter which site caused the request. That convenience is the vulnerability. A page on an attacker’s domain can cause your browser to fire a request at your bank, and the browser will dutifully include your cookie, so the request arrives fully authenticated as you. The attacker never touched your credentials. They borrowed your browser’s habit of presenting them.
The idea
CSRF is a confused-deputy attack: the browser is a deputy that automatically attaches your credentials, and the attacker abuses it to issue state-changing requests you never intended. The reason it is defeasible is an asymmetry in the same-origin model: an attacker can make your browser send a cross-site request, but cannot read the response to one. Every good defense turns on that gap.
The mechanism
OWASP’s definition is precise: “Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.” The word forces is doing work. The victim does not consent to the action; they merely visit a page, and hidden markup on that page, an image tag, an auto-submitting form, triggers the request. Because the target site is one where the victim is already logged in, the browser supplies the session cookie, and the server sees a well-formed, authenticated request.
The key is whose authority is used. OWASP: “It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf.” The server cannot distinguish this forged request from a genuine one, because in every dimension it checks, the credentials, the session, it is genuine. Only the intent is forged.
Why it targets state changes, not reads
There is a natural limit to what CSRF can do, and it explains the shape of every real attack. OWASP: “Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does.” The same-origin policy stops the attacker’s page from reading the bank’s response. So CSRF cannot be used to steal data off the screen. It can only be used to cause an effect, transfer funds, change an email, delete an account, anything whose value is in the request being processed rather than in the reply being read.
The token defense exploits the same asymmetry
If the attacker can send but not read, then require, on every state-changing request, a secret they would have to read to include. That is the synchronizer token pattern. The server plants an unpredictable value in the page (and the session) and demands it back with the request. OWASP states the logic directly: “CSRF tokens prevent CSRF because without a CSRF token, an attacker cannot create valid requests to the backend server.” The token must be “Unique per user session,” “Secret,” and “Unpredictable (large random value generated by a secure method).” The attacker’s page can forge the request, but it cannot fetch the victim’s page to learn the token, and it cannot guess it. The forged request arrives without a valid token and is rejected.
Why the cookie alone cannot be the check
Suppose the server tried to authenticate a transfer using only the session cookie. The browser attaches that cookie automatically to the attacker’s forged request, so the check passes and the transfer goes through. Add a token that lives in the page body rather than in an auto-sent cookie, and the picture changes: the browser does not attach page-body values on its own, and the attacker cannot read the page to supply one. The defense works by requiring a credential the browser will not volunteer and the attacker cannot obtain.
SameSite cookies, as a second layer
Modern browsers add a structural control. The SameSite cookie attribute tells “the browser [to] decide whether to send cookies along with cross-site requests,” with Strict, Lax, or None. Set appropriately it can stop the cookie from riding along on a cross-site request in the first place, cutting the attack off before the token check. OWASP is careful about its scope, though: “SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments,” partly because Lax “still allows the cookie on top-level navigations that use safe methods.” Tokens remain the primary defense; SameSite hardens the perimeter around them.
Related Notes
- Cross-Site Scripting (XSS), the sibling web attack, and the one that can steal a CSRF token when both are present
- The OWASP Top 10, for where web risks like this rank across real applications
- STRIDE Threat Modeling, which names the spoofing and tampering threats CSRF realizes
Sources
- “Cross Site Request Forgery (CSRF),” OWASP Foundation. https://owasp.org/www-community/attacks/csrf . Supports that CSRF “forces an end user to execute unwanted actions on a web application in which they’re currently authenticated,” that “It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf,” and that “Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does.”
- “Cross-Site Request Forgery Prevention Cheat Sheet,” OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html . Supports that “CSRF tokens prevent CSRF because without a CSRF token, an attacker cannot create valid requests to the backend server,” the token requirements (unique per session, secret, unpredictable), that the SameSite attribute controls “whether to send cookies along with cross-site requests,” and that “SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments.”