skip to content

Why can a cookie sent with no SameSite attribute still ride a cross-site POST minutes after it was set?

level: seniorimportance: nice to knowfreq 28%

answer

  1. a mode, never an attribute value
  2. only cookies that named nothing
  3. unsafe method, top-level, cross-site
  4. MAY apply, SHOULD limit by age
  5. 2 minutes is guidance, not a rule

basics

~20 s

Because of a compatibility enforcement mode, not an attribute value. A user agent may treat a cookie that set no SameSite attribute as Lax while still allowing it on cross-site top-level requests with unsafe methods for a short period after creation; two minutes is cited as a reasonable limit.

solid answer

~50 s

The mode is called **Lax-allowing-unsafe**, and the first thing to know is that it is not something a server can write: there is no such attribute value. It is enforcement behaviour a user agent **may** apply, and only to cookies that specified **no** `SameSite` attribute at all. Under it, such a cookie is treated as Lax in general but is still attached to a cross-site top-level request using an unsafe method, for a limited time after the cookie was created. The specification **should**-restricts it to recently created cookies and records that deployment experience names **2 minutes** as a reasonable limit. The practical consequence is that a session cookie is at its most forgeable in the minutes right after it is issued — which is also when a user who just followed a notification link is most active. Setting `SameSite=Lax` explicitly takes the cookie out of the mode entirely.

code

http · 2 lines
http
HTTP/1.1 200 OK
Set-Cookie: session=6f1a9c2e4b7d; Path=/; Secure; HttpOnly

go deeper

for a junior

The takeaway is narrow: a cookie that names no SameSite value is not the same as one that says Lax, because clients may treat the two differently just after the cookie is created.

for a middle

Be able to name the three conditions that scope the mode: no attribute was set, the request is a cross-site top-level one with an unsafe method, and the cookie was created recently.

for a senior

Show you read specification modals precisely — a MAY for the mode, a SHOULD for the age restriction, and a number that is deployment guidance — and that you would not let a defence depend on any of the three.

for a principal

The broader point is that part of this defence lives on a side of the exchange you do not control and cannot observe, so it belongs in a risk model as a variable rather than in a design as a guarantee.

## A mode, not a value The legal values of the `SameSite` cookie attribute are `Strict`, `Lax` and `None`. **Lax-allowing-unsafe is none of them.** It is an *enforcement mode* — behaviour on the client side, described in `RFC 6265bis (draft-ietf-httpbis-rfc6265bis)`, that exists to soften the breakage caused by treating attribute-less cookies as Lax. No server ever asks for it, no `Set-Cookie` header can select it, and nothing in an arriving request announces that it was applied. That framing matters because engineers meeting the name in a write-up often try to configure it, or assume a colleague configured it. There is nothing to configure. The only lever a server has is the opposite one: state a value explicitly, and the mode no longer applies. ## Exactly what it is scoped to Three conditions narrow it, and every one of them is part of the answer: 1. **Only attribute-less cookies.** A cookie whose `Set-Cookie` carried no `SameSite` attribute at all. A cookie that says `SameSite=Lax` in so many words is outside the mode. 2. **Only cross-site top-level requests with an unsafe method.** Ordinary Lax already permits the safe-method top-level navigation; the mode adds the unsafe-method top-level request on top, which in practice means a cross-site form POST that navigates the top-level context. 3. **Only for a short time after the cookie was created.** The age restriction is the part written as a recommendation, and the number attached to it is guidance drawn from deployment experience. ## How strongly the specification states it This is the part most worth getting exactly right, because promoting any of it to a rule teaches a false certainty: | Element | Strength as specified | |---|---| | Applying the mode at all | **MAY** — a user agent is permitted to, not required to | | Restricting it to recently created cookies | **SHOULD** | | 2 minutes as the age limit | Named by deployment experience as a reasonable limit — guidance, not a mandated constant | So you can neither rely on the window existing nor rely on its exact size. A client may not implement the mode; a client that does may pick a different age; the behaviour may change between versions of the same client. Any defence whose correctness depends on the number is not a defence. ## Why the window sits in the worst possible place A cookie is at age zero immediately after it is issued, and the moment a session cookie is issued is the moment a user signs in. So the interval in which an attribute-less session cookie is *most* forgeable is the interval just after authentication — the same interval in which a user who arrived by following a link out of a notification message is clicking through the service. The window is short, but it is not randomly placed relative to user activity; it overlaps the busiest part of a session's life. It is also the interval an attacker can influence. Anything that causes a fresh credential to be minted resets the age, so the window is not a one-shot opportunity that expires on its own timetable. ## What to do with this - **State the attribute explicitly.** A cookie that says `SameSite=Lax` is out of the mode's scope; an attribute-less cookie is in it wherever the mode is implemented. This is the only part of the behaviour a server influences. - **Do not reason about the number.** Treat 2 minutes as a description of one deployment's experience rather than a boundary you can build on, and never state it to a colleague as the rule. - **Read it as evidence for the leaf's whole point.** A compatibility mode that re-opens the unsafe-method path for the newest cookies is precisely why the specification says Lax enforcement "does not offer a robust defense against CSRF as a general category of attack". A defence that can be silently relaxed by the client, within limits the server cannot observe or verify, is defence in depth and nothing more. The question an interviewer is really asking with this one is whether you can distinguish **what a specification requires, what it recommends and what it merely permits** — and whether you noticed that this behaviour lives entirely on a side of the exchange you do not control.

  • Does setting SameSite=Lax explicitly change anything, if Lax is what an attribute-less cookie gets anyway?
    Yes. The compatibility mode is scoped to cookies that specified no SameSite attribute at all, so writing the value explicitly takes the cookie out of the mode and removes the unsafe-method window wherever a client implements it. The two are not equivalent, even though both end up described as Lax.
  • Can a server tell whether a client applied the mode to a given request?
    No. The request carries an ordinary Cookie header and nothing that reports which enforcement mode produced it. That is the general shape of the problem: SameSite is enforced entirely by the user agent, so the server can neither observe nor verify the decision it made.

saying these in an interview costs you the question

  • Calls Lax-allowing-unsafe a value you set on the cookie
  • States the two-minute window as a specification requirement
  • Believes the mode applies to cookies that say SameSite=Lax
  • Assumes every client implements the mode identically
  • Thinks the window is visible to the server in the request