Requests you did not make

How can a site you are not even looking at act as you on one you are?

The browser keeps sites apart. A page on one origin cannot read another origin's pages, cookies, or storage; the same-origin policy has enforced that for decades and it is one of the reasons the web is usable at all.

So here is the puzzle. Under that regime, a page on an attacker's site can still cause your bank to move money. Nothing was read. No isolation was broken. The bank checked your session and found it valid, because it was valid. Which means the separation the browser enforces is not quite the separation we assumed it was, and the gap is worth locating exactly.

Ask a narrow question first: when the browser decides whether to attach your session cookie to an outgoing request, what does it consult?

It consults the destination. A request headed for your bank's domain gets your bank's cookies. That is the whole rule, and notice what is absent from it: any consideration of which page caused the request. A form submitted by the bank's own page and a form submitted by an attacker's page are, at the moment the cookie is attached, indistinguishable.

That property has a name worth keeping — ambient authority. Your credential is not something a request carries because someone deliberately supplied it; it hangs in the air around the browser and settles on any request pointed the right way. Authority attaches to the destination rather than to the intent.

So the attack writes itself. A page you visit contains a hidden form aimed at the bank's transfer endpoint, submitted by script the moment the page loads. The browser attaches your cookie, the bank sees an authenticated request, and it does what it was told.

Now ask what the attacker gets back. Nothing readable — the same-origin policy still applies to the response. This is genuinely a one-way attack: it can cause effects but cannot observe them. Which tells you where the risk concentrates. Endpoints that change state are exposed; endpoints that merely return data are largely not, since the attacker cannot read what comes back.

How do you close it? The requirement is to make requests caused by your own pages distinguishable from requests caused by anyone else's. Two families of answer exist.

The first is to require something the attacker cannot know. Because the attacker cannot read your bank's pages, a random per-session value embedded in each of the bank's own forms is unavailable to them — the synchroniser token pattern. The token is not secret from you; it is secret from a party who can send requests but not read replies, and that asymmetry is exactly the one the same-origin policy already guarantees.

The second is to make the browser stop attaching the cookie. That is what the SameSite attribute does, and it is worth being precise about its reach because it is routinely overstated. SameSite=Strict withholds the cookie on every cross-site request. SameSite=Lax — which Chrome has applied as the default for cookies with no explicit attribute since 2020, though browsers have differed on this — withholds it on cross-site subrequests and form posts, but still sends it on top-level navigations that use safe methods. So a state-changing endpoint reachable by GET remains exposed under Lax, and Chrome additionally allows a brief grace window for top-level posts with very recently set cookies.

There is a second limit. SameSite compares registrable domains, not origins. A sibling subdomain is same-site, so a compromised or attacker-controlled host under the same domain is not held off by it at all.

Checking the Origin header is a third, cheaper defence, and a reasonable belt to the token's braces.

Three refinements.

First, nothing here is a failure of authentication. The bank's check was correct: the session really is yours. The missing check is a different one — not who is this, but did this user's own interface produce this request. Confusing the two is why the bug survives code review so often.

Second, an anti-forgery token protects a request, not a page. It must be validated on every state-changing endpoint, and it must be bound to the session; a token accepted from any session, or checked only on the endpoints someone remembered, defends nothing. The "double-submit cookie" variant, which compares a cookie against a form field without server-side binding, is weaker for a reason already met elsewhere in this cluster: an attacker who can set cookies on the domain can set both halves.

Third, do not treat SameSite as a replacement for tokens. It is a strong second layer whose exact behaviour depends on the browser, the method, and the domain relationship — three variables outside your control. Defence in depth here is not caution, it is a response to genuine uncertainty about what the client will do.

• Why the same-origin policy restricts reads but historically not writes, and what that trade bought the early web.
• Capability-based security as the general alternative to ambient authority.
• How SameSite interacts with federated login flows that legitimately cross sites.

Every term the collection defines is gathered in the glossary.