Cross-Site Request Forgery (CSRF) Explained
Cross-Site Request Forgery abuses a simple fact about how browsers work: they automatically attach a user's stored credentials, typically session cookies, to every request sent to a domain, regardless of which site actually triggered that request.
How the attack actually works
An attacker crafts a page, or embeds content, that causes a victim's browser to send a request to a target application the victim happens to be logged into. Because the browser automatically attaches the victim's session cookie, the target application sees what looks like a completely legitimate request from an authenticated user, with no way to tell it was not intentionally initiated by that user.
What makes an application vulnerable
An application that relies solely on session cookies to authenticate state-changing requests, changing a password, transferring funds, updating an email address, with no additional verification that the request actually originated from the application's own pages, is vulnerable by default.
The standard defenses
- Anti-CSRF tokens. A unique, unpredictable value embedded in each form, verified server-side, that an attacker's forged request has no way to know or include.
- SameSite cookie attributes. Modern browsers support cookie settings that prevent cookies from being sent along with cross-site requests in the first place, closing much of the gap at the browser level rather than requiring every application to defend itself individually.
- Checking the Origin or Referer header. A weaker, supplementary defense, since these headers can occasionally be absent or manipulated in edge cases, but still useful as a second layer.
Why it still appears in modern applications
Frameworks increasingly include CSRF protection by default, which has reduced how often this appears in greenfield applications. It still shows up regularly in older codebases, custom-built authentication flows, and APIs that were designed assuming a bearer token model but still accept cookie-based session authentication on the side. It remains one of the categories worth explicitly testing for rather than assuming a framework default has it fully covered.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation