Secure Is Not Enough: How Far Does Your Session Cookie Reach?

A session cookie has Secure, HttpOnly, and SameSite=Lax. At first glance, the security review looks reassuring.

Then somebody notices Domain=example.com.

The session no longer belongs only to app.example.com. The browser may also send that cookie to matching subdomains. Those subdomains might contain marketing pages, support tooling, an old campaign site, a customer-facing WordPress installation, or a service operated by a third party. One small configuration choice has created a much larger trust zone.

The useful audit question is therefore not only: Does the session cookie have the usual flags? It is: How far is this cookie allowed to travel, and is that scope actually necessary?

Cookie security is a set of different boundaries

Cookie attributes solve different problems. They are not interchangeable.

Secure limits transmission to secure channels. HttpOnly keeps the cookie out of normal JavaScript cookie APIs. SameSite controls when the browser sends it in cross-site contexts. Domain and Path, however, determine which hosts and paths are eligible to receive it.

That is why a cookie is not automatically well-scoped merely because three familiar flags are present.

Consider:

Set-Cookie: session=...; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax

The value is transported over HTTPS and hidden from ordinary JavaScript access. Its host scope is still broader than a host-only cookie without Domain.

1. Domain defines part of your trust zone

The current IETF cookie work describes the behavior directly: when Domain=site.example is present, the cookie applies to that domain and matching subdomains. If Domain is omitted, the cookie remains bound to the host that set it.

For an application running at app.example.com, one question should be explicit:

Does any other subdomain genuinely need the same session?

Quite often, the answer is no.

Broad domain cookies still appear for understandable historical reasons:

• Frontend and API were once split across subdomains.
• An old SSO setup expected shared cookies.
• A framework example was copied into production.
• Staging, admin, and app briefly shared authentication.
• Infrastructure changed, but nobody narrowed the cookie afterward.

The risk is organizational as much as technical. Every additional subdomain becomes part of the session model. A forgotten microsite, outdated CMS, or poorly controlled external service can become security-relevant far beyond its business importance.

The current IETF draft also calls out the underlying integrity problem: sibling subdomains do not inherently provide strong cookie integrity boundaries. A sibling can, under the applicable rules, set a cookie for a parent domain. That is exactly the kind of accidental coupling an audit should expose.

2. Path is routing scope, not a strong security boundary

It can be tempting to isolate sensitive cookies with Path=/admin or Path=/account.

That changes which requests receive the cookie, but it is not a reliable isolation mechanism between applications on the same host. Both current IETF work and MDN warn against treating Path as a security boundary.

If two applications have genuinely different trust levels, separate hosts are usually a cleaner boundary than separate paths on one origin.

Path remains useful. It simply should not be asked to do the job of host separation, authorization, or a well-designed session architecture.

3. SameSite has to match the real authentication journey

SameSite supports Strict, Lax, and None. More restrictive values reduce the cross-site contexts in which the browser sends the cookie.

That does not mean “Strict is always better” for every production application.

A login may return from an external identity provider. Users may come back from an email, payment provider, or partner portal. Embedded applications have different constraints again. An overly restrictive setting can break legitimate journeys; an unnecessarily open setting expands exposure.

So SameSite should be selected and tested intentionally:

• Does ordinary sign-in work?
• Does the OAuth/OIDC callback work?
• Do magic links and password-reset links work?
• Do payment or booking redirects work?
• Is a cross-site POST genuinely required?
• Are there embedded contexts that truly need cookies?

SameSite=None should not become a generic “make it compatible” switch. Modern browser behavior pairs it with Secure, and it should be reserved for flows that actually require cross-site cookie delivery.

Also, SameSite is a valuable layer against some cross-site request attacks. It is not a replacement for server-side authorization or automatically a complete CSRF strategy for every application.

4. HttpOnly protects the value, not every action

HttpOnly is highly appropriate for session identifiers because the browser will not expose such cookies through ordinary JavaScript cookie APIs.

But that does not make XSS harmless.

If attacker-controlled JavaScript executes inside your application, it may be unable to copy an HttpOnly session value directly from document.cookie, yet it can still perform actions within the page context, trigger requests, or manipulate visible data if the application permits it.

HttpOnly closes an important theft path. It does not replace XSS prevention, Content Security Policy, safe rendering, or server-side permission checks.

5. __Host- turns an architectural intention into a browser check

Cookie prefixes are useful because they do more than describe what developers intended. Supporting browsers enforce specific conditions when the cookie is set.

A cookie name beginning with __Host- has three central requirements:

• Secure must be present.
• Path must be /.
• Domain must be absent.

The result is host-only scope rather than a domain cookie shared across sibling subdomains.

For a conventional first-party web application, a name such as __Host-session is therefore a powerful review prompt: If this session is needed only on one host, why should the configuration permit anything broader?

The weaker __Secure- prefix requires Secure but still allows Domain.

Current IETF work and MDN also document newer prefixes such as __Http- and __Host-Http-, which add HttpOnly requirements. They are useful signals of where browser-enforced cookie properties are heading, but they should not become the only control: browser support and the actual client matrix still need verification.

Six red flags a cookie audit should catch

1. Session cookies use Domain=example.com by default

If only app.example.com needs the session, the additional reach is an unnecessary expansion of trust.

2. Marketing, CMS, and application hosts share one cookie domain

Technically independent systems with very different maintenance standards should not accidentally end up inside the same session boundary.

3. SameSite=None was added “so everything works”

That often indicates that nobody modeled the actual cross-site journey that required it.

4. Path is presented as protection between admin and public apps

A path can limit when the cookie is sent, but it is not a strong security boundary.

5. Login sets one cookie and logout removes a different variant

Cookie removal has to line up with the cookie identity and scope that were originally set. Old Domain or Path variants can otherwise survive and turn debugging into a small haunted house.

6. Nobody can explain which cookie actually authenticates the user

Frameworks, reverse proxies, auth SDKs, and application APIs can create several similarly named cookies. Without an inventory, teams may not know which one is security-critical.

A practical 20-minute test

Open the application in a clean browser profile and inspect cookies before login, after login, and after logout.

For every authentication-related cookie, record:

• name
• issuing host
• Domain
• Path
• Secure
• HttpOnly
• SameSite
• expiry or session behavior
• whether a prefix is used
• which component sets it
• where the server accepts it

Then test the boundaries deliberately:

1. Open a sibling subdomain and inspect which cookies are sent there.
2. Test login and logout across every real application host.
3. Test OAuth, magic links, password reset, and external redirects.
4. Confirm that logout invalidates the relevant server-side session rather than only removing a visible cookie.
5. Repeat in the browsers your users actually run.
6. Inspect the real production Set-Cookie headers. Framework configuration and delivered headers are not the same thing.

What Website-Pflichtencheck would inspect

A session-cookie review should not stop at a checklist in the DevTools cookie panel. The actual subject is the trust boundary:

• Which hosts share authentication?
• Which cookies exist before and after login?
• Is Domain genuinely required?
• Does SameSite match real cross-site journeys?
• Are Secure and HttpOnly applied consistently?
• Could __Host- or another prefix reduce ambiguity?
• Are stale or duplicate cookie variants still present?
• Does logout invalidate the session server-side?
• Can marketing, CMS, staging, or third-party systems influence the session scope?
• Are CSRF and XSS controls resilient independently of cookie flags?

The biggest improvement from this kind of audit is often not an exotic browser trick. It is a smaller trust zone.

A session cookie should not travel farther just because it technically can. It should travel exactly as far as the application genuinely needs.