skip to content

Your server sets SameSite=Lax on a session cookie — what can the server verify about whether that attribute was honoured?

level: juniorimportance: should knowfreq 56%

answer

  1. the client enforces, the server declares
  2. no return channel
  3. the Cookie header looks identical
  4. unknown attributes are simply ignored
  5. absent, not weakened

basics

~20 s

Nothing. SameSite is enforced entirely by the client; the server only writes the attribute into Set-Cookie. An arriving request carries an ordinary Cookie header that looks the same whether the client honoured the attribute or never implemented it at all.

solid answer

~50 s

`SameSite` is a **request to the user agent**, and the whole of the enforcement lives there. The server writes the attribute onto `Set-Cookie` once; from then on the client decides, request by request, whether to attach the cookie, and it reports that decision to nobody. What reaches the server is a `Cookie` header — byte-identical whether a conforming client applied Lax and this request was genuinely allowed, or a client that never implemented the attribute ignored it and attached the cookie to a cross-site POST. For that second client the defence is **absent, not weakened**: there is no degraded mode, the attribute is simply skipped. This is why the specification itself says Lax enforcement "does not offer a robust defense against CSRF as a general category of attack", and why the check that actually gates a state change has to be one the server performs on the request it received.

code

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

go deeper

for a junior

Remember which side acts: your server writes the attribute once, and the client decides every time whether to send the cookie. Nothing in the arriving request tells you what it decided.

for a middle

Be able to explain why an unrecognised cookie attribute is ignored rather than fatal, and what that means for a client that predates SameSite: no enforcement at all, and no signal.

for a senior

Show that you model the non-implementing client population as unprotected when assessing residual risk, and that the control you rely on is one evaluated on the request the server holds.

for a principal

The framing to bring is that a delegated, unobservable control belongs in a risk model as an assumption rather than in a design as a guarantee, which is what makes the server-side check the load-bearing one.

## The attribute is a request to the client A `Set-Cookie` response header carries a name, a value and a list of attributes. Attributes are **instructions to the user agent about its own future behaviour**: how long to keep the cookie, which hosts to send it to, whether to send it over an unencrypted connection, whether script may read it, and — with `SameSite` — whether to attach it to a request caused by a document from another site. Every one of those is enforced on the client side. The server participates exactly once, when it writes the header. It never sees the enforcement happen, and there is no return channel by which a client reports which rules it applied. ## What the server actually receives On a later request the cookie arrives in a `Cookie` request header: a name and a value, and nothing else. The attributes are not echoed back. The server cannot tell: - which `SameSite` value the client believes this cookie has; - whether this request was judged same-site or cross-site; - whether the client implements the attribute at all; - whether a compatibility mode relaxed the rule for this particular request. So "the cookie is marked Lax, therefore this request must be same-site or a safe-method navigation" is an inference the server is not entitled to make. It has the same evidence either way. ## A client that never implemented the attribute Cookie attributes are ignored when unrecognised — that is how the format is designed to be extended, and it is what allowed `SameSite` to be deployed at all without breaking existing clients. The consequence for a defence built on it is blunt: | Client | What it does with `SameSite=Lax` | CSRF exposure | |---|---|---| | Implements the attribute | Withholds the cookie from cross-site subresource loads and form POSTs | Narrowed to the safe-method navigation carve-out | | Does not implement it | Skips the token it does not recognise and attaches the cookie as before | Unchanged from having no attribute | The second row is the one people state wrongly. It is not "a weaker version of the protection"; the protection is **not present**. There is no partial enforcement, no fallback and no warning. The population of such clients is one you do not control and cannot enumerate: old embedded browsers, kiosk and set-top clients, in-application viewers, scripted clients and anything else that speaks HTTP and keeps a cookie jar. ## Absent, not weakened — and why the distinction matters A weakened defence still shifts the odds; an absent one does not. When you reason about residual risk you have to model those clients as if the attribute were never set, which means the question becomes: **what protects a state change when the cookie attribute contributes nothing?** That is the honest framing, and it is the framing the cookie specification itself adopts when it declines to present Lax as a general defence. ## What the server can check The checks a server can actually rely on share one property: they are evaluated **on the request the server received**, not on a promise about a decision made elsewhere. 1. **A value the server issued.** Bound to the session, unpredictable, and carried in the request; a document from another origin cannot read it out of your pages, so it cannot supply it. 2. **A field describing where the request came from.** The client states the origin that caused the request, and the server compares it against what it permits. Both of those are the subject of their own mechanisms and their own failure modes. The point here is narrower: they are decisions the server makes with evidence in hand, while `SameSite` is a decision the server delegates and cannot audit. ## The one-line version Setting `SameSite` is worth doing — it removes real attack vectors on the clients that implement it, which is most traffic. Believing that setting it has *verified* anything is the mistake. A cookie attribute is a hope about the far end of the connection; a server-side check is a fact about the request in front of you.

  • Why does a client that does not implement SameSite leave the defence absent rather than degraded?
    Because an unrecognised cookie attribute is ignored outright — that is how the cookie format is extended without breaking older clients. There is no partial enforcement to fall back on, so such a client attaches the cookie exactly as it would have before the attribute existed, and nothing signals that to the server.
  • If the server cannot verify the attribute, is setting it still worth doing?
    Yes, as defence in depth. On clients that implement it the attribute removes the cross-site subresource and form-POST vectors outright, which is most traffic and a genuine reduction. What it cannot do is carry the weight alone, because its enforcement is unobservable and its scope has known holes.

It is a note on an envelope asking the courier not to hand it over at certain doors. A courier who knows the convention complies, one who never learned it delivers anyway, and the recipient cannot tell which courier brought the envelope.

saying these in an interview costs you the question

  • Thinks the server can see which SameSite value the client applied
  • Says an arriving cookie proves the request was same-site
  • Believes an unrecognised attribute makes a client reject the cookie
  • Treats a non-implementing client as having weaker rather than no protection
  • Assumes every HTTP client with a cookie jar is a modern browser