Cybersecurity glossary
What is Cross-Site Request Forgery (CSRF)?
Learn what Cross-Site Request Forgery (CSRF) is, how attackers forge state-changing requests using a victim’s session, and how anti-CSRF tokens, SameSite cookies, and safe methods prevent it.
Definition
Cross-Site Request Forgery (CSRF) is an attack that tricks a victim’s browser into sending an authenticated request to a trusted site, causing a state-changing action without the user’s intent by abusing ambient credentials such as session cookies.
Why CSRF matters
Users stay logged into email, banking, SaaS, and admin consoles for convenience. Browsers help by storing session cookies and attaching them to requests. Cross-Site Request Forgery (CSRF) turns that convenience into a weapon: a malicious page can instruct the browser to call a sensitive endpoint on another site, and the cookies go along for the ride.
The victim does not hand over a password. They simply visit the wrong page while authenticated. The trusted application performs a real action in their name.
How CSRF works
Victim authenticates
The user logs into a vulnerable site and receives a session cookie.
Attacker crafts a request
A hostile page includes a form, image tag, or scripted request aimed at the vulnerable endpoint.
Victim visits the hostile page
Social engineering, ads, or compromised sites deliver the CSRF payload.
Browser sends ambient credentials
For eligible cross-site requests, cookies for the target site are attached automatically.
Server accepts the action
Without anti-CSRF controls, the application treats the request as intentional.
State changes in the victim’s account
Email, password, payments, or permissions change without informed consent.
What CSRF is not
| Topic | Distinction |
|---|---|
| XSS | Injects attacker script into the trusted origin; can steal data or tokens directly. |
| CSRF | Uses the victim browser to forge requests to the trusted origin without reading the response. |
| Clickjacking | Hijacks a real UI click on an embedded trusted page. |
| CORS misconfig | May allow malicious JS to read responses; different failure mode than forging state changes. |
Common impact scenarios
Account takeover setup
Change email or disable MFA endpoints become the path to lasting compromise.
Financial actions
Transfers, purchases, or payout destination updates execute under the victim session.
Admin operations
Privileged consoles create users, approve access, or alter security settings.
OAuth / linking abuse
Victim accounts silently grant access to an attacker-controlled client.
Effective defenses
Defense in depth works best: reject forged requests and reduce automatic credential sending.
- Use synchronizer anti-CSRF tokens or double-submit patterns verified on all state-changing requests.
- Prefer SameSite=Lax or Strict cookies for session credentials where application flows allow.
- Do not perform state changes via GET; reserve safe methods for reads.
- Require re-authentication or step-up for irreversible account and money operations.
- Validate Origin and Referer as additional signals where they are present and reliable.
- For APIs, prefer Authorization headers over cookie sessions for pure cross-site SPA architectures when practical.
- Ensure tokens are unique per session, unpredictable, and checked server-side—never only in JavaScript UX.
- Test with an external HTML page that attempts forged POSTs while authenticated.
Frameworks often provide CSRF middleware. Confirm it covers JSON endpoints, mobile webviews, and alternate hostnames—not only classic HTML forms.
The practical takeaway
CSRF abuses authenticated browser sessions to perform actions the user did not intend. The forged request is real; the intent is not.
Prevent it with anti-CSRF tokens, thoughtful cookie SameSite settings, safe HTTP method usage, and step-up checks on high-risk operations. If a cookie-authenticated action can be triggered by any cross-site request without a secret the attacker cannot read, CSRF remains possible.
Related security terms
Same-Origin Policy (SOP)
Explains why browsers send cookies on cross-site requests while restricting response reads.
Session Management
Cookie and session design choices that strongly influence CSRF exposure.
Clickjacking
A related UI abuse class that hijacks genuine clicks rather than forging standalone requests.
Cross-Site Request Forgery
Vulnerability-focused deep dive on CSRF exploitation and remediation patterns.
Frequently asked questions
What is CSRF in simple terms?
CSRF tricks your browser into making a request to a site where you are already logged in. The site thinks you asked for the action—like changing an email—because your session cookie was sent automatically.
Does CSRF steal cookies?
Classic CSRF does not need to read cookies. It abuses the browser’s habit of attaching cookies to requests. XSS that steals cookies is a different problem.
Which requests are CSRF targets?
State-changing actions authenticated by cookies or similar ambient credentials: password changes, transfers, email updates, OAuth approvals, and admin operations.
How do anti-CSRF tokens work?
The server embeds a secret token in forms or headers that an attacker’s cross-site page cannot read. The server rejects state-changing requests that lack a valid token.
Do SameSite cookies stop CSRF?
SameSite=Lax or Strict reduces many cross-site cookie sends and helps a lot, but is not a complete substitute for tokens on all architectures, especially with older browsers or special cookie setups.
Can APIs using Bearer tokens suffer CSRF?
If credentials are only in custom headers and not attached automatically by the browser, classic cookie CSRF risk drops. Cookie-based session APIs remain in scope.
Is CORS a CSRF defense?
No. CORS mainly controls whether JavaScript can read responses. Browsers may still send simple cross-site requests that change state.
References
Explore authoritative guidance and frameworks related to cross-site request forgery (csrf).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.