SameSite Cookies Draw a Site Boundary That Is Broader Than Origin

Two HTTPS applications can be isolated by the browser’s same-origin policy yet still occupy the same cookie site. A service at accounts.example.com and another at shop.example.com have different origins because their hosts differ, but cookie policy can classify their request context at a broader site boundary. That gap matters when SameSite is treated as if it were equivalent to origin isolation.

The SameSite attribute controls cookie attachment in cross-site request contexts. It does not turn a cookie into an origin-scoped credential, and it does not replace application authorization or request-specific anti-forgery controls. Its security effect comes from a browser classification step performed before eligible cookies are attached to an HTTP request.

The same-origin policy primarily constrains script access between origins. An origin is defined by scheme, host, and port. Cookie scoping follows different rules: host or domain matching, path matching, secure transport requirements, expiry, and same-site processing all contribute to whether a stored cookie accompanies a request.

SameSite adds context about the request’s relationship to a site. Modern browser behavior is scheme-aware, so an HTTPS page and an HTTP page associated with the same registrable domain can be treated as cross-site for this purpose. Port is not the differentiator that it is for origin identity.

This creates a security boundary with a different shape. Sibling HTTPS hosts beneath the same registrable domain can be cross-origin while remaining same-site. A design that grants untrusted content control of a sibling host therefore cannot assume that SameSite=Strict creates isolation equivalent to placing that content on a separate site.

The distinction is architectural rather than cosmetic. Origin controls and cookie site controls protect different transitions.

Strict blocks cross-site attachment, not sibling-site influence

A cookie marked SameSite=Strict is withheld when the request is cross-site. That is a strong restriction on ambient credential attachment, but the classification is only as narrow as the site boundary.

Consider an authenticated application on portal.example.com and a separately operated application on uploads.example.com. If both are HTTPS and fall within the same site, a request initiated from the second host toward the first can be same-site even though browser script rules still regard the two origins as distinct.

As a result, Strict does not establish distrust between sibling origins within one site. If a security model requires one sibling host to be hostile to another, site-level cookie controls alone do not express that boundary.

Cookie scope adds another dimension. A host-only session cookie can prevent the cookie itself from being sent to sibling hosts, while still being attached to requests sent to its owning host from a same-site sibling context. The browser distinguishes the destination eligible to receive the cookie from the context used for SameSite classification.

Lax preserves selected navigation flows

SameSite=Lax permits same-site attachment and also allows cookies in selected cross-site top-level navigation cases. This supports common flows in which a user follows a link from another site and arrives with an existing session.

That exception means Lax is not a blanket prohibition on cross-site credential delivery. Request method and navigation context matter. Embedded resource requests and many programmatic cross-site requests do not receive the same treatment as qualifying top-level navigation.

Security analysis must therefore focus on the state-changing endpoint rather than the cookie label alone. An application that performs sensitive changes through navigation-compatible request patterns can erase part of the protection it expected from Lax. HTTP method semantics, endpoint behavior, and cookie attachment rules have to agree.

Browser defaults also make explicit attributes preferable for security-sensitive cookies. Current browser behavior commonly treats an omitted SameSite attribute with Lax-like restrictions, but explicit policy avoids making the application’s intended boundary depend on an implicit default.

None deliberately restores cross-site credential attachment

SameSite=None declares that the cookie may be sent in both same-site and cross-site contexts. Current browser processing requires such cookies to carry the Secure attribute, tying their transmission to secure transport.

That combination solves a real interoperability requirement for applications that need credentials in cross-site embeds or other cross-site flows. It also removes the cross-site attachment restriction that Strict or Lax would have supplied.

Secure does not compensate for that removal. It protects the transport channel used to send the cookie; it does not determine whether the initiating context is trusted. A cross-site HTTPS request can still be cross-site and can still receive a SameSite=None; Secure cookie when other cookie matching rules permit it.

Systems using None therefore need a separate control for unwanted authenticated actions. Depending on the application, that can include anti-forgery tokens, request-origin validation, interaction requirements, or protocol-specific state binding. SameSite can contribute defense in depth, but None explicitly opts out of its cross-site withholding behavior.

Domain scope can enlarge the credential-management surface

The Domain attribute permits a cookie to cover a parent domain and matching subdomains rather than only the host that set it. This is independent of SameSite classification, but the two mechanisms interact operationally.

A broadly scoped cookie creates more hosts at which the cookie can be relevant. If sibling applications have different administrative or deployment trust, that expansion can turn a convenient shared session mechanism into a larger credential boundary.

Host-only cookies reduce that surface. Cookie name prefixes can impose additional browser-enforced constraints in supporting user agents. In particular, a __Host- cookie must be set from secure transport, must use Path=/, and must omit Domain, keeping its delivery bound to the setting host rather than a parent-domain scope.

Those constraints still do not make SameSite an origin policy. They narrow where a cookie can be sent and who can define a competing broadly scoped form, while SameSite continues to classify request context at the site level.

Scheme changes can cross the site boundary

Scheme-aware same-site processing closes an older ambiguity in which HTTP and HTTPS resources associated with the same registrable domain could be treated as belonging to one site despite their transport difference.

This matters during partial HTTPS migrations. A navigation or request crossing between http://example.com and https://example.com can encounter SameSite restrictions even though the host portion is unchanged. Applications that rely on mixed-scheme flows can therefore see credential behavior change when strict site classification is applied.

The security benefit is that an insecure transport context does not automatically receive same-site standing relative to its HTTPS counterpart merely because the domain matches. The operational cost is that legacy mixed-scheme assumptions become visible as authentication or session failures.

HSTS addresses a related but separate boundary by causing eligible HTTP URLs to be upgraded before insecure transport is used. SameSite still governs cookie attachment based on request context; HSTS does not replace that classification.

SameSite is a request-context control, not an authorization decision

The browser can decide whether a cookie is eligible for a request, but it cannot decide whether the resulting authenticated action is permitted by application policy. A request carrying a valid session can still target the wrong object, exceed a principal’s privileges, or invoke an operation that needed stronger confirmation.

SameSite also does not neutralize script execution inside a trusted site. If an attacker gains script execution in an application origin, the request may be generated from a context that already satisfies same-site rules. HttpOnly can prevent direct script reads of a session cookie, but it does not stop the browser from attaching that cookie to requests made from an eligible context.

The practical boundary is therefore precise: SameSite reduces ambient cookie attachment across site transitions. It is most effective when the site’s administrative trust matches that browser boundary, state-changing endpoints use appropriate HTTP semantics, and independent authorization and anti-forgery controls remain in place where the application requires them.

Treating site and origin as interchangeable collapses two browser security models into one. Keeping them separate makes the remaining trust assumptions visible: which hosts share a site, which hosts may initiate authenticated requests, which cookies are host-bound, and which operations require evidence beyond ambient session state.

Cybersecurity Cookies SameSite CSRF