SameSite=Strict protects a redelivery session cookie; what does it stop from a compromised host under the same registrable domain?

seniorshould knowfreq 44%

answer

site, not origin
registrable domain is the unit
a sibling is inside the boundary
Strict and Lax are identical here
no attribute narrows below the domain

basics

~20 s

Nothing at all. Same-site is decided on the registrable domain, so any host beneath it is same-site with the service and its requests carry the session cookie in full, under Strict exactly as under Lax. SameSite is not a boundary between your own hosts.

solid answer

~50 s

Same-site and same-origin are different tests, and SameSite uses the looser one. The attribute is evaluated against the registrable domain, so status.redelivery.example, an old marketing host and a vendor-operated subdomain are all same-site with redelivery.example even though none of them is same-origin with it. A document on any of those hosts can emit a request of any method and any shape, and a conforming client treats it as same-site and attaches the session cookie — SameSite=Strict never enters the decision, because there is nothing cross-site to refuse. No cookie attribute narrows this: the cookie is being sent to your own host by a client that considers the requesting document part of your site. Only a check that discriminates by origin — a value the hostile document cannot obtain, or a server-side comparison of where the request claims to come from — separates the two.

Same-site and same-origin are different tests, and `SameSite` uses the looser one. The attribute is evaluated against the **registrable domain**, so `status.redelivery.example`, an old marketing host and a vendor-operated subdomain are all same-site with `redelivery.example` even though none of them is same-origin with it. A document on any of those hosts can emit a request of any method and any shape, and a conforming client treats it as same-site and attaches the session cookie — `SameSite=Strict` never enters the decision, because there is nothing cross-site to refuse. No cookie attribute narrows this: the cookie is being sent to your own host by a client that considers the requesting document part of your site. Only a check that discriminates by **origin** — a value the hostile document cannot obtain, or a server-side comparison of where the request claims to come from — separates the two.

code

http · 7 lines

http

POST /reschedule HTTP/1.1
Host: redelivery.example
Origin: https://promo.redelivery.example
Content-Type: application/x-www-form-urlencoded
Cookie: session=6f1a9c2e4b7d

parcel=8812&slot=2026-09-22T09%3A00

go deeper

for a junior

Hold on to the one fact: hosts sharing your registrable domain count as the same site, so the session cookie goes with their requests no matter which SameSite value you chose.

for a middle

Be able to state the two tests side by side and say which one the attribute uses: same-origin compares scheme, host and port, while same-site compares the registrable domain, and SameSite acts on the second.

for a senior

Demonstrate that you count every host under the registrable domain as part of the service's attack surface, including ones other teams or vendors operate, and that you reach for an origin-granular check rather than another cookie attribute.

for a principal

The judgment call is domain topology: putting an untrusted or externally operated property under the same registrable domain as a cookie-authenticated service permanently widens the trust boundary, and moving it to a separate domain is the structural fix.

The boundary SameSite actually draws

A cookie attribute can only act on a decision the user agent makes, and the decision SameSite acts on is same-site, not same-origin. Same-site is computed from the registrable domain, the name immediately beneath a public suffix. Same-origin is stricter: it needs scheme, host and port to match exactly. The consequence is short and load-bearing.

Host issuing the request	Same-origin with `https://redelivery.example`?	Same-site with it?	Session cookie attached?
`https://redelivery.example`	Yes	Yes	Yes
`https://status.redelivery.example`	No	Yes	Yes
`https://promo.redelivery.example`	No	Yes	Yes
`https://attacker.example`	No	No	Governed by the attribute

Only the last row is a case SameSite has any opinion about. For the middle two, the attribute is never consulted, because the request was never cross-site.

What a foothold on a sibling host buys an attacker

Suppose a long-forgotten promotional microsite under the same registrable domain is compromised — an abandoned build pipeline, an expired vendor contract, a subdomain pointed at a third-party host that someone else has since claimed. A document served from there can:

emit a form POST to the redelivery service with any body encoding, and the session cookie is attached;
emit a request using any method at all, safe or unsafe, with no carve-out needed;
do this while the session cookie is marked SameSite=Strict, which changes nothing.

There is no gradation here. Against a same-site host, Strict and Lax are identical and both are inert. The attacker is not evading the attribute; the attacker is inside the boundary the attribute draws.

Why hardening the cookie does not close it

The reflex is to reach for another attribute, and none of them applies:

Secure governs the transport the cookie may travel over, not which document caused the request.
HttpOnly stops script from reading the cookie's value. The attack never reads it — the client attaches it automatically, which is the whole of ambient authority.
Narrowing where the cookie is stored and sent to does not help either, because the cookie is being sent to your own host. The hostile document does not need to receive your cookie; it only needs to cause a request that carries it.

That last point is the one that trips people. "A sibling host can read my cookie" and "a sibling host can cause my cookie to be sent" are different claims with different mechanisms, and this leaf is the second one.

What does still discriminate

Two classes of check survive, because both operate at origin granularity rather than site granularity:

Something the hostile document cannot obtain. A value bound to the session that the server issued and stores, which a document on another origin cannot read out of your pages, and which must accompany the state change.
A server-side comparison of the request's declared source. A request carries a field naming the origin that caused it, and https://promo.redelivery.example is not https://redelivery.example. An exact comparison against a list of permitted origins rejects the sibling; a prefix or suffix comparison does not, which is its own failure mode.

Both of those are separate mechanisms with their own trade-offs; the point here is only that they see a distinction the cookie layer does not.

The trust consequence worth stating out loud

The registrable domain, not the origin, is the unit of trust for cookie-borne credentials. Whatever your service's own security posture, its effective attack surface includes every host anybody can stand up under that domain: a status page, a documentation site, a conference microsite, a staging host left resolvable, a subdomain delegated to a platform that recycles names. Each of those is a place from which a fully authenticated state-changing request can be launched at you, and SameSite will be no part of the story.

The practical reading is that a cookie-authenticated service should treat subdomain sprawl as a security concern rather than a tidiness concern, and should not count any cookie attribute as separating it from hosts it does not operate.

## The boundary SameSite actually draws A cookie attribute can only act on a decision the user agent makes, and the decision `SameSite` acts on is **same-site**, not same-origin. Same-site is computed from the **registrable domain**, the name immediately beneath a public suffix. Same-origin is stricter: it needs scheme, host and port to match exactly. The consequence is short and load-bearing. | Host issuing the request | Same-origin with `https://redelivery.example`? | Same-site with it? | Session cookie attached? | |---|---|---|---| | `https://redelivery.example` | Yes | Yes | Yes | | `https://status.redelivery.example` | No | Yes | Yes | | `https://promo.redelivery.example` | No | Yes | Yes | | `https://attacker.example` | No | No | Governed by the attribute | Only the last row is a case `SameSite` has any opinion about. For the middle two, the attribute is never consulted, because the request was never cross-site. ## What a foothold on a sibling host buys an attacker Suppose a long-forgotten promotional microsite under the same registrable domain is compromised — an abandoned build pipeline, an expired vendor contract, a subdomain pointed at a third-party host that someone else has since claimed. A document served from there can: - emit a form POST to the redelivery service with any body encoding, and the session cookie is attached; - emit a request using any method at all, safe or unsafe, with no carve-out needed; - do this while the session cookie is marked `SameSite=Strict`, which changes nothing. There is no gradation here. Against a same-site host, `Strict` and `Lax` are identical and both are inert. The attacker is not evading the attribute; the attacker is **inside the boundary the attribute draws**. ## Why hardening the cookie does not close it The reflex is to reach for another attribute, and none of them applies: - `Secure` governs the transport the cookie may travel over, not which document caused the request. - `HttpOnly` stops script from reading the cookie's value. The attack never reads it — the client attaches it automatically, which is the whole of ambient authority. - Narrowing where the cookie is *stored and sent to* does not help either, because the cookie is being sent **to your own host**. The hostile document does not need to receive your cookie; it only needs to cause a request that carries it. That last point is the one that trips people. "A sibling host can read my cookie" and "a sibling host can cause my cookie to be sent" are different claims with different mechanisms, and this leaf is the second one. ## What does still discriminate Two classes of check survive, because both operate at origin granularity rather than site granularity: 1. **Something the hostile document cannot obtain.** A value bound to the session that the server issued and stores, which a document on another origin cannot read out of your pages, and which must accompany the state change. 2. **A server-side comparison of the request's declared source.** A request carries a field naming the origin that caused it, and `https://promo.redelivery.example` is not `https://redelivery.example`. An exact comparison against a list of permitted origins rejects the sibling; a prefix or suffix comparison does not, which is its own failure mode. Both of those are separate mechanisms with their own trade-offs; the point here is only that they see a distinction the cookie layer does not. ## The trust consequence worth stating out loud The registrable domain, not the origin, is the unit of trust for cookie-borne credentials. Whatever your service's own security posture, its effective attack surface includes **every host anybody can stand up under that domain**: a status page, a documentation site, a conference microsite, a staging host left resolvable, a subdomain delegated to a platform that recycles names. Each of those is a place from which a fully authenticated state-changing request can be launched at you, and `SameSite` will be no part of the story. The practical reading is that a cookie-authenticated service should treat subdomain sprawl as a security concern rather than a tidiness concern, and should not count any cookie attribute as separating it from hosts it does not operate.

Does marking the session cookie HttpOnly help against a compromised sibling host?
No. HttpOnly stops script from reading the cookie's value, and this attack never reads it. The hostile document causes a request to your host and the client attaches the credential by itself. HttpOnly is aimed at a different problem — a script that has already run on a page and wants to exfiltrate the credential.
Why does a check on where the request came from see a distinction that SameSite does not?
Because it compares at origin granularity. The requesting origin is the full scheme, host and port, so promo.redelivery.example is plainly not redelivery.example, while the same-site test collapses both onto the shared registrable domain. The comparison must be exact — a suffix match reintroduces the same hole.

saying these in an interview costs you the question

Says a sibling subdomain is a separate origin, so the cookie is withheld
Believes Strict is stricter than Lax against a same-site host
Treats same-site and same-origin as the same test
Thinks HttpOnly or Secure limits which host can cause a request
Assumes a subdomain you do not operate is outside your trust boundary

SameSite=Strict protects a redelivery session cookie; what does it stop from a compromised host under the same registrable domain?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The boundary SameSite actually draws

What a foothold on a sibling host buys an attacker

Why hardening the cookie does not close it

What does still discriminate

The trust consequence worth stating out loud

▾common follow-ups2 questions

▾red flags5 flags

The boundary SameSite actually draws

What a foothold on a sibling host buys an attacker

Why hardening the cookie does not close it

What does still discriminate

The trust consequence worth stating out loud

answer

go deeper