Cross-Site Request Forgery (CSRF)
Also known as: CSRF · XSRF
Cross-Site Request Forgery (CSRF) abuses the fact that browsers automatically attach credentials (cookies) to requests. If a state-changing endpoint relies solely on ambient authentication and lacks anti-CSRF protection, an attacker can craft a page that causes the victim's browser to perform actions - transfers, email changes, privilege grants - as the victim.
How it works
- 1A state-changing endpoint authenticates via cookies alone, with no anti-CSRF token or same-site protection.
- 2The victim, while logged in, visits an attacker-controlled page.
- 3That page auto-submits a forged request to the target with the victim's cookies attached.
- 4The server processes it as a legitimate action by the victim.
Example
<form action="https://bank.example/transfer" method="POST" id="f">
<input name="to" value="attacker">
<input name="amount" value="5000">
</form>
<script>f.submit()</script>Impact
CSRF can change account settings, move funds, escalate privileges, or link accounts - any state change reachable with the victim's ambient session.
Remediation
- Use anti-CSRF tokens (synchronizer or double-submit) on all state-changing requests.
- Set cookies to SameSite=Lax or Strict as appropriate.
- Require re-authentication or a challenge for sensitive actions.
- Prefer non-cookie auth (Authorization headers) for APIs.
Detection & testing
Check that state-changing endpoints require an unpredictable, validated token and are not exploitable cross-site. Confirm SameSite cookie behavior.
Impactr tests for Cross-Site Request Forgery (CSRF) the way an attacker would - investigating, chaining it with related flaws, and proving impact with a reproducible exploit before it reaches your report.
Test my app for CSRFTools
Frequently asked questions
Does SameSite=Lax fully stop CSRF?
SameSite cookies mitigate many CSRF vectors but are not a complete control on their own - top-level GET navigations and certain flows can still be abused. Combine SameSite with anti-CSRF tokens.