SameSite Defence Gaps

## Why this service cannot use Strict People reach the parcel redelivery service by following a link out of a notification message, so the first request of nearly every session is a **cross-site top-level navigation**. `SameSite=Strict` would withhold the session cookie from precisely that navigation: the user taps the link they were told to tap and lands on the scheduling page signed out. `SameSite=Lax` exists for this shape of service. Once it is settled, the honest question is not what Lax protects but what it leaves forgeable. ## What Lax attaches, and what it withholds Under `SameSite=Lax` a conforming user agent attaches the cookie to: - every **same-site** request, of any method and any shape; - a **cross-site top-level navigation** whose method is safe in the `RFC 9110` sense — `GET`, `HEAD`, `OPTIONS`, `TRACE`. Everything else that is cross-site goes without it: | Cross-site request a hostile document can emit | Session cookie attached under Lax? | |---|---| | Image, script, stylesheet or frame subresource load | No | | Auto-submitting form POST (`application/x-www-form-urlencoded`, `multipart/form-data`, `text/plain`) | No | | Scripted call made in credentialed mode | No | | Top-level navigation using `GET` | **Yes** | | Top-level navigation using `POST` | No — except under a compatibility mode that applies only to cookies that set no `SameSite` attribute at all | The first two rows are the vectors most people picture when they hear "cross-site request forgery", and Lax genuinely removes them. That is real value, and it is why the attribute is worth setting. It is also the whole of what it buys. ## The gap: anything that changes state on a safe method The carve-out is **method-shaped**, not intent-shaped. The user agent has no idea whether `/reschedule?parcel=8812&slot=...` writes to a database; it sees a `GET`, sees a top-level navigation, and attaches the credential. A hostile page reaches that with ordinary markup — a `<meta http-equiv="refresh">` in the top-level document, or an anchor the victim is induced to click. The attacker never reads the response and does not need to: the redelivery slot has already moved. This is why an audit of a Lax-protected service is an audit of its **safe-method writes**. Endpoints spelled as a `GET` because they started life as a convenience link — cancel, confirm, unsubscribe, reschedule, a one-click action embedded in an email — sit entirely outside the attribute's protection, while the team believes a cookie attribute has covered them. ## Safeness is judged on the hop, not on what the page emitted The second half of the gap is subtler. A method may change across a redirect: a `POST` answered with `301 Moved Permanently` or `302 Found` is customarily reissued as a `GET`, while `307 Temporary Redirect` and `308 Permanent Redirect` preserve the method. Safeness is evaluated against **the request actually being made on the current hop**. So: 1. a hostile top-level document submits a form to a host the attacker controls; 2. that host answers `302 Found` with a `Location` pointing at `https://redelivery.example/reschedule?...`; 3. the hop the user agent now performs is a `GET` top-level navigation — safe, cross-site, therefore permitted; 4. the session cookie is attached. The exchange began as a cross-site `POST`, which Lax would have refused, and finished as something Lax allows. Reasoning about "the method the attacker used" rather than "the method on this hop" is the usual way this is missed. ## What the specification itself says `RFC 6265bis (draft-ietf-httpbis-rfc6265bis)` does not present Lax as a solution. Its own verdict is that Lax enforcement "does not offer a robust defense against CSRF as a general category of attack", and in its place it sketches a **two-cookie session design**: issue one read-only credential that is allowed to travel on cross-site requests, so the inbound link still renders a signed-in page, and a second read-write credential that is withheld from cross-site requests entirely, with every state-changing endpoint requiring the second. That splits the entry-path requirement away from the write path instead of trading one against the other. ## What to carry away SameSite is **defence in depth**. It narrows the set of documents that can spend your user's ambient authority; it does not remove the ambient authority, and the narrowing has a precise, method-shaped hole in it. The check that actually gates a state change is one the server performs on the request itself — a value it issued and can verify, or a comparison of where the request says it came from — and those are separate mechanisms with separate failure modes.