How do you keep a double-submit CSRF value stateless while making a value planted by a sibling host fail the check?

## Bind the value to the session, not to itself Every weakness of the plain pattern reduces to one sentence: **the check verifies that two strings are equal, and equality is a property the attacker can arrange.** The repair is to make the value carry a proof that it was minted by your server *for this session*, so that equality stops being sufficient and provenance becomes checkable without a lookup. The standard construction is two-part: - a fresh **random part**, which keeps values distinct and unguessable; - a **keyed message authentication code** over the session identifier joined to that random part, computed with a secret only your servers hold. The cookie carries both parts, and the page echoes both parts back. The server never stores anything: it already receives the session identifier on the request, so it can recompute the code and see whether it matches. That is the trick — the binding is *recomputable*, not *remembered*. ## What the server does on each request 1. Read both copies — the one in the `Cookie` request header, and the submitted one. **Absent either, reject.** 2. Compare them. Unequal, reject. 3. Split the value into its random part and its code. 4. Recompute the code from the server secret, the session identifier carried on this request, and that random part. 5. Mismatch, reject; match, accept the write. Step 4 is the whole difference. Steps 1 and 2 are what the plain pattern already did, and on their own they accept a planted pair happily. ## Why a planted pair now fails A sibling host under the shared registrable domain still has the ability to write a cookie your host will read — that capability is a property of the cookie layer and no application-level change removes it. What changes is that writing a cookie is no longer enough: | What the attacker can do | Result against the plain pair | Result against the session-bound pair | |---|---|---| | Invent a value and plant it in a cookie | Accepted — both halves match | Rejected — no valid code over the victim's session identifier | | Harvest a valid value from his own logged-in session and plant that | Accepted — both halves match | Rejected — the code is bound to *his* session identifier, not the victim's | | Replay a value the victim used earlier in the same session | Accepted | Accepted — this construction binds to the session, not to a single request | That last row is the honest limit. Session binding closes cookie injection; it does not by itself make a value single-use, and a value the victim's own page exposed to an attacker in the same session still verifies. ## What the cookie-name hardening adds, and what it does not Naming the cookie with the `__Host-` prefix constrains how the cookie may be **set**: a cookie whose name carries that prefix is not accepted by a conforming browser when it comes with a `Domain` attribute, which is exactly the write a sibling host needs for its cookie to reach your host. It is real hardening and it is nearly free. Be honest about its shape, though: - It constrains **where the cookie may be set**, not **who may run script in the user's browser**. Script executing in a page on *your own* host is unaffected by the prefix. - It is enforced by the browser, so it protects users on conforming clients and says nothing about anything else. - It is a second lock, not the lock. A deployment that relies on the prefix alone, with an unsigned self-referential value underneath, has one mechanism between it and a forged write. The layered version is: bind the value cryptographically **and** name the cookie so the parent-scoped write is refused. The first makes a planted value useless; the second makes planting it harder in the first place. ## Costs and edges worth stating - **The secret becomes an asset.** It must be generated properly, distributed to every instance, and rotated. Rotation needs an overlap window where the previous secret still verifies, or every in-flight form breaks at the moment of the rotation. - **Login must reissue.** The code is bound to a session identifier, so when that identifier changes the old value stops verifying. Issue a fresh pair as part of establishing the new session, or the user's first write after signing in is rejected. - **Anonymous requests have no session to bind to.** A pre-login form has no identifier, so decide deliberately what the binding is there rather than silently falling back to the plain, self-referential form. - **Cookies are not isolated by port or by scheme.** The binding does not care — it is checked by your server — but do not describe the port or the scheme as the thing that saved you.