Design Session Cookies Across Subdomains Without Widening Risk

Reviewed: 2026-09-06 (UTC)

Prefer a host-only session for each application

Prefer host-only session cookies for each application and a central identity endpoint that checks or exchanges login state. A Domain cookie sent to every sibling subdomain makes any weaker or abandoned sibling part of the authentication boundary. RFC 6265 defines how host-only and Domain cookies behave, and its security considerations explain why broader cookie scope increases exposure.

If you fully control every sibling subdomain and intentionally treat them as one authentication boundary, a parent-domain cookie can be a simpler tradeoff, but it widens the blast radius of any subdomain compromise.

Exchange login state between app and admin hosts

For app.example.com and admin.example.com, let the identity service keep its own host-only cookie. Each application can then complete a short front-channel or back-channel exchange and mint its own application-scoped session. In practice, that keeps the browser from automatically presenting one shared session cookie to every sibling host while still allowing a smooth sign-in experience.

Ory Kratos documentation on multi-domain cookies is relevant here because it documents the underlying cookie behavior that matters for this design: cookies ignore ports, subdomains can set cookies for parent domains, and Kratos lets you configure cookie domain, path, and SameSite settings. When you want separate application sessions instead of one parent-domain session, those mechanics are exactly what you are trying to constrain.

Reduce the shared boundary

A parent-domain cookie is sent to matching subdomains, and some subdomains can also set cookies scoped to the parent domain, which expands the authentication boundary. Before you accept that scope, inventory marketing tools, abandoned hosts, customer-controlled content, preview environments, and takeover-prone DNS entries under the parent domain. RFC 6265 specifically calls out weak confidentiality, weak integrity, and reliance on DNS in its security considerations, which is a good match for this risk review.

For app and admin hosts, bind the exchange to a one-time value, an exact return location, the intended audience, and a short expiry. Rotate the application session after the exchange so a value captured for one host does not simply become the long-lived session for another.

If you are implementing this with Ory, Ory Kratos is an API-first identity and user management system for login and related self-service identity flows, and Ory Hydra documentation covers OAuth 2.0 and OpenID Connect when you need a standards-based authorization layer for that central identity endpoint or exchange.

Test cookie ambiguity

Because cookies with the same name can coexist under different scope attributes, test how your framework handles them and avoid relying on a single surfaced value. Prefer distinct cookie names per scope, and clear legacy cookies during migration. RFC 6265 defines the Cookie and Set-Cookie mechanisms and is the right reference when you test how your applications parse and replace cookies.

Exercise an attacker-controlled sibling, a duplicate cookie, a cross-site POST, an expired exchange, and logout from one or all applications. Verify Secure, HttpOnly, and SameSite behavior in the browsers you support, and use the browser vendors’ current behavior as the final check rather than assuming every client handles edge cases identically. Also verify sign-out propagation explicitly, including what happens when one sibling application or the identity service is temporarily unavailable.

Your next step is practical: draw the full hostname inventory for the parent domain, mark which teams control each host, and only choose a parent-domain cookie if you are willing to make every one of those hosts part of the same authentication boundary.