Cross-site request forgery (CSRF)

CSRF exists because browsers historically attached ambient credentials (cookies, HTTP Basic credentials, client certificates) to every request for a site, whatever page initiated it. A cross-origin page can cause GET requests with an img or link, and POST requests with an auto-submitted form using the three "simple" content types (application/x-www-form-urlencoded, multipart/form-data, text/plain) without a CORS preflight. The same-origin policy blocks the attacker from reading the response, but a state change on the server has already happened. The attack is therefore blind and one-way; it only works when the attacker can predict every parameter of the request.

Variants widen the scope. Login CSRF logs the victim into the attacker's account so later activity (searches, stored card details) is recorded where the attacker can see it. JSON endpoints are vulnerable if the server parses a text/plain body as JSON or does not check Content-Type. State-changing GET handlers are exploitable from any image tag. Routers and other devices on the local network have been attacked through CSRF from a web page, since the browser sits inside the network. An XSS flaw on the same site defeats every CSRF defence, because script running in the origin can read tokens and send same-origin requests.

The OWASP prevention cheat sheet treats a synchronizer token or a signed double-submit cookie as the classic primary defence and, for modern browsers, also accepts Fetch Metadata checks as a primary control: reject unsafe methods such as POST when Sec-Fetch-Site is cross-site. Custom request headers suit API-only endpoints, since a cross-origin page cannot set one without a preflight that the server can refuse. Defence in depth adds SameSite cookies and verification of the Origin header. Chromium has treated cookies without a SameSite attribute as Lax since 2020, which blocks most cross-site POSTs but still allows top-level GET navigations, and Lax does nothing against same-site attacks from a sibling subdomain.

CSRF was in the OWASP Top 10 as its own category in 2007, 2010 and 2013 and was dropped in 2017, largely because frameworks such as Django, Rails, ASP.NET Core and Spring Security enable token protection by default; it is catalogued as CWE-352. The remaining failures are usually custom endpoints that opt out of framework protection, token checks applied only to POST, and APIs that switched from bearer headers to cookies without adding a defence.