Cross-site request forgery

Cookies were designed to be attached to every request to their domain, regardless of which page initiated it.

That is what keeps a visitor signed in when they follow a link from elsewhere, and it is the same behaviour that makes this possible.

So the server receives a genuine session cookie on a request the visitor did not intend, and nothing in the request distinguishes the two cases.

The target is therefore any state-changing operation reachable with just a session: a settings change, a transfer, a deletion.

The SameSite attribute tells the browser whether to attach a cookie on requests initiated by another site.

Lax attaches it on ordinary navigations and withholds it on cross-site form submissions and background requests, which removes the most common shape of the problem.

Strict withholds it on every cross-site request, which is safer and means a visitor following a link from elsewhere arrives signed out.

Browsers now default to Lax where the attribute is absent, which means many sites received the mitigation without doing anything — and a site explicitly setting None gave it up.

None is legitimate for genuine cross-site usage and requires Secure alongside it, which browsers enforce.

A token the server issues and the form returns, which the other site cannot read because the same-origin policy prevents it.

Checking the Origin header on state-changing requests, which browsers send and which another site cannot forge.

Requiring a custom header, which triggers a preflight the other site cannot satisfy without permission.

Re-authenticating for the operations that matter most, which is the only defence that also covers a visitor whose session was stolen outright.

The SameSite value on each cookie, including the ones declaring None and whether they carry Secure as browsers require.

Which cookies look session-related, and whether they combine Secure, HttpOnly and a strict SameSite.

Whether a login area exists at all, which is what makes any of this relevant to a given site.

Not whether tokens are used or validated, and not whether the Origin header is checked — both are server-side behaviour an anonymous observation cannot see.

Anything that changes state and is reachable with a session alone: a settings change, a password change, a deletion, a transfer.

Not read operations, which disclose nothing the other site could not already request on its own behalf.

Operations reached only through a method a form cannot produce are harder to target and are not therefore protected.

The practical rule is that every state change gets the protection, because deciding case by case is how one gets missed.