Cross-Site Request Forgery (CSRF)
CWE-352: Cross-Site Request Forgery (CSRF)
Cross-site request forgery abuses the fact that browsers automatically attach cookies to requests. If a state-changing request can be triggered from another site and the server only checks the session cookie, an attacker page can make the victim's browser perform actions the victim never intended, such as changing an email address or transferring funds. The attacker cannot read the response; the damage comes from the action itself being accepted under the victim's identity.
Ranks change between editions as the underlying CVE data changes, so exam questions rarely hinge on an exact rank. Know what each weakness is, how it is exploited, and how it is prevented.
How it shows up in the real world
- A hidden auto-submitting form on an attacker's page posts to a bank's transfer endpoint while the victim is logged in.
- An image tag pointing at a GET endpoint that changes account settings, so simply viewing an email or forum post triggers the change.
- A router admin panel on the local network accepts configuration changes from any origin, letting a web page change its DNS settings.
How to mitigate it
- Require an unpredictable, per-session anti-CSRF token on every state-changing request, validated on the server.
- Set session cookies with SameSite=Lax or Strict so browsers do not send them on cross-site subrequests.
- Never perform state changes on GET requests, and verify the Origin or Referer header on sensitive endpoints.
- Require re-authentication or a second factor for high-impact actions such as password, email, or payment changes.
Go deeper
Practice this topic
Test your knowledge of Cross-Site Request Forgery (CSRF) with exam-style practice questions.