Cross-site request forgery (CSRF)

Cross-site request forgery abuses the fact that browsers attach credentials automatically. If a session lives in a cookie, that cookie travels with any request to the matching domain regardless of which page caused the request to be sent. An attacker therefore does not need to steal anything. They need only get an authenticated visitor to load a page that fires a request at your application — a form posted by script, an image tag pointing at an endpoint that accepts a GET — and your server sees a properly authenticated call.

The distinction from cross-site scripting is worth holding onto, because the two are routinely confused in questionnaires and remediation reports. Scripting is a failure to control what executes inside your origin. Forgery involves no code running on your site at all: it is a failure to establish that a legitimate, authenticated request was also an intentional one. The attacker never sees the response, which is why the technique targets actions with side effects rather than data to be read.

The defences that hold

• The SameSite cookie attribute, which instructs the browser not to attach a session cookie to cross-site requests. Lax is now the default in major browsers and removes the simplest version of the attack outright.
• An anti-forgery token that the server issues, the page echoes back, and the server verifies — the point being that an attacker cannot read the token out of a page on a different origin.
• Verifying the Origin header on state-changing requests, which is cheap, and useful precisely because the browser will not let a hostile page forge it.
• Never accepting a state change over GET. An endpoint that mutates data on a plain link visit is exploitable through markup that runs no script whatsoever.

A token stored in a cookie and echoed in a header is not automatically protection: the value has to be one the attacking origin cannot read or predict.