Cross-Site Request Forgery (CSRF)
TL;DR
Cross-Site Request Forgery (CSRF) tricks a logged-in user’s browser into making a state-changing request they didn’t intend. The fix is anti-CSRF tokens and sensible SameSite cookies.
Only test apps you’re authorised to test.
What it is
Browsers attach a site’s cookies to every request to that site, even ones triggered from another page. If an app relies only on the cookie being present to trust a request, an attacker’s page can quietly make the victim’s browser perform an action — change an email, transfer something — while they’re logged in elsewhere.
How it works
The attacker gets the victim to load a page that auto-submits a request to the target app. The victim’s session cookie rides along, and if there’s no unpredictable token proving the request came from the real app, it goes through. It only works on actions that change state and rely on cookies alone.
How to test for it
- Take a state-changing request and see if it still succeeds without a unique per-request token.
- Check whether the app validates that token, or just ignores it.
- Look at the session cookie’s
SameSitesetting.
How to fix it
- Use anti-CSRF tokens on every state-changing request and validate them server-side.
- Set cookies to
SameSite=LaxorStrict. - Most modern frameworks include CSRF protection — turn it on rather than rolling your own.
Reference: OWASP: CSRF and the prevention cheat sheet.