SameSite Cookies Make Site Context Part of Session Delivery

HTTP cookies are ambient credentials in many web applications. Once a browser stores a session cookie, matching requests can carry it automatically; application code does not have to attach the credential to every request. That convenience also creates a security problem: a page on another site may cause the browser to issue a request to the authenticated application.

The SameSite cookie attribute adds request context to the browser’s delivery decision. A cookie can still match its domain, path, expiry, and transport requirements, yet be withheld because the request is cross-site. The control therefore changes where part of the session boundary is enforced: before the credential reaches the server.

Site and origin are different boundaries

SameSite is based on the web’s site concept, not the same-origin policy. For cookie processing, modern schemeful same-site rules distinguish sites using the URL scheme together with the registrable domain. Ports do not create separate sites for this decision.

That distinction matters for sibling hosts. https://app.example.com and https://accounts.example.com can be same-site even though they are different origins. JavaScript access between those origins remains constrained by the same-origin policy, but SameSite cookie evaluation can treat requests between them as same-site.

This makes SameSite a poor substitute for origin-level authorization. A security design that assumes every sibling subdomain is mutually untrusted cannot rely on the attribute alone to create that separation.

Strict removes the cross-site delivery path

A cookie marked SameSite=Strict is withheld on cross-site requests. A typical session cookie can combine that rule with transport and script-access restrictions:

Set-Cookie: session=opaque-value; Path=/; Secure; HttpOnly; SameSite=Strict

The useful property is not that the remote site is unable to send a request. Browsers can still perform many cross-site navigations and submissions. The property is that the eligible Strict cookie does not accompany a request whose site context is cross-site.

That changes the server-visible request. An endpoint that depends on the session cookie no longer receives the ambient credential through that cross-site path.

The tradeoff is visible in ordinary navigation. A user following a link from another site arrives without a Strict cookie on that cross-site navigation. Applications that expect authenticated state to survive such entry paths may need a less restrictive policy or a separate flow.

Lax keeps a narrow navigation exception

SameSite=Lax withholds the cookie from many cross-site subresource requests and unsafe cross-site actions, while allowing it on qualifying top-level navigations that use safe methods. This preserves common link-navigation behavior without making the cookie broadly available to cross-site requests.

The distinction is important for state-changing endpoints. A state transition exposed through GET is unsafe regardless of cookie policy. Safe HTTP methods are expected not to request a state change, and Lax behavior relies on that semantic boundary for its top-level navigation exception.

Applications should therefore keep mutation semantics aligned with HTTP methods. SameSite=Lax can reduce credential delivery on cross-site POST requests, but it cannot repair an endpoint that performs sensitive mutations through a safe method.

Browser handling of cookies that omit the attribute has also evolved toward Lax-style defaults. Explicit attributes remain preferable because they make the intended session policy visible in configuration rather than relying on an implicit browser default.

None deliberately restores cross-site delivery

Some applications require a cookie in a third-party context, such as an embedded service that must maintain its own session while framed by another site. SameSite=None expresses that the cookie may be sent in both same-site and cross-site contexts.

Current browser rules pair SameSite=None with Secure:

Set-Cookie: embed_session=opaque-value; Path=/; Secure; HttpOnly; SameSite=None

None is not a weaker spelling of Lax; it selects a different delivery model. Once cross-site cookie delivery is required, the application has intentionally reopened the path that Strict and Lax constrain. The server then needs controls appropriate to the operation, including request-specific anti-CSRF defenses where ambient credentials can authorize state changes.

Secure protects cookie transmission by restricting delivery to secure transport. It does not establish that a cross-site request was intended by the account holder.

SameSite reduces CSRF exposure but does not define authorization

Cross-site request forgery depends on more than the ability to create an HTTP request. The forged request must also carry authority that the target accepts. Session cookies are a common source of that ambient authority, so suppressing them in cross-site contexts removes an important path.

The boundary is still incomplete. Same-site attackers can exist, especially when an organization hosts less-trusted applications on sibling subdomains. Some application flows intentionally use SameSite=None. Other credentials may be delivered through mechanisms unrelated to cookies. Server endpoints can also have authorization defects that no cookie attribute can correct.

For sensitive mutations, request-specific anti-CSRF tokens remain useful because the server can require a value that a generic cross-site submission cannot supply. Origin-related request metadata can provide another signal where deployment constraints permit it. These controls address different parts of the request-authentication problem.

Cookie scope still matters inside the site boundary

SameSite does not replace Domain, host-only cookies, Path, Secure, or HttpOnly. Each attribute constrains a different aspect of cookie storage or delivery.

A host-only session cookie avoids deliberately extending the cookie to sibling hosts through a Domain attribute. Secure restricts network delivery to secure transport. HttpOnly prevents ordinary script access through document.cookie, reducing one direct cookie-theft path when script execution is compromised. Path influences request matching but is not an isolation boundary between mutually untrusted applications.

These properties compose. A session cookie can be host-only, secure, unavailable to JavaScript, and restricted by same-site context at the same time. Treating any single flag as the complete session boundary leaves other delivery paths outside the model.

The browser enforces a credential-delivery policy

SameSite is most precise when treated as a browser-side credential-delivery rule. The server declares a policy when setting the cookie; the browser later evaluates request context before deciding whether that cookie is eligible for the Cookie header.

That placement is valuable because an unwanted credential can be withheld before the request reaches application authorization logic. It also sets the limit of the mechanism. The attribute controls cookie attachment, not request creation, user intent, endpoint semantics, or authorization correctness.

A robust session design uses that narrow property deliberately: cookie scope limits where the credential can travel, SameSite limits which site contexts can carry it, and server-side controls decide whether the resulting request is authorized.

Reference: Cookies: HTTP State Management Mechanism — RFC 6265bis draft