What Is Cross-Site Request Forgery (CSRF)?
Cross-site request forgery (CSRF) tricks a logged-in user’s browser into sending a request the user never intended. The attacker cannot see the response — they exploit the fact that the browser automatically attaches the victim’s session cookie to any request to the target site, including one triggered from a malicious page. The result is an action performed as the victim.
How does a CSRF attack work?#
The attack rides on ambient authority — the browser’s habit of sending cookies with every request to a site, regardless of who initiated it:
- The victim is logged in to
bank.example(a session cookie exists). - They visit a malicious page, which contains a hidden form or image pointing at
bank.example/transfer. - The browser sends that request with the victim’s cookie attached.
- The bank sees a valid, authenticated request and processes the transfer.
Nothing was stolen — the browser did exactly what it always does. That is why CSRF targets state-changing actions (transfers, password changes), not data reads.
How do you prevent CSRF?#
Modern defenses are layered, and the first is now built into browsers:
| Defense | How it stops CSRF |
|---|---|
SameSite cookies | Browser withholds the cookie on cross-site requests |
| Anti-CSRF tokens | A secret the attacker’s page cannot know or read |
| Re-authentication | Confirm sensitive actions with a fresh check |
Checking Origin/Referer | Reject requests from unexpected origins |
SameSite=Lax (now the browser default) blocks the classic attack for most cases; a
per-session anti-CSRF token, tied to the session,
covers the rest. Together they are robust.
CSRF is the counterpart to XSS in the browser-security story, governed by the same-origin policy and cookie attributes. More at the Web Security hub.
Frequently asked questions#
What is CSRF in simple terms?
Cross-site request forgery tricks a victim’s browser, which is already logged in to a site, into sending a state-changing request the victim never intended — like changing their email or transferring money. The attacker cannot read the response; they abuse the fact that the browser automatically attaches the victim’s session cookie.
What is the difference between CSRF and XSS?
XSS runs the attacker’s script inside the trusted site and can read data. CSRF cannot read anything — it only forces a request using the victim’s existing session. XSS is more powerful and actually defeats most CSRF defenses, which is why fixing XSS is a prerequisite for CSRF protection to mean anything.