CSRF
Cross-Site Request Forgery
0 / 4 solved
Make a signed-in browser perform state-changing actions from an unrelated website.
Quick reference
CSRF cheat sheet
Look for state-changing browser requests that rely only on cookies or other ambient credentials and do not verify that the request came from the legitimate UI.
Where to look
- Email/password/profile changes, API key actions, payment settings, security preferences, invitations, deletes, and administrator actions.
- Prioritize endpoints authenticated by cookies and actions that can be represented by ordinary links or forms.
- Check whether POST/PUT/DELETE requests contain an unpredictable anti-CSRF token and whether Origin/Referer is validated.
Simple checks
- First establish a normal authenticated session on the victim site, then reproduce the state-changing request from a genuinely different site.
- Remove the CSRF token or test whether a token is static/reusable across users or sessions.
- Check whether GET endpoints incorrectly change state and inspect Origin/Referer on sensitive POST requests.
<form method='POST' action='https://target.example/account/email'>...</form><a href='https://target.example/settings/disable-alerts'>open resource</a>Realistic tips
- SameSite helps but is defense-in-depth; it does not replace sound request semantics and anti-CSRF controls.
- Tokens should be unpredictable and correctly bound/validated, not static values shipped to every user.
- Origin/Referer checks are useful additional defenses for sensitive browser workflows.