Shared subdomains create security risk because browsers cannot infer organisational trust from DNS labels alone. Without an explicit boundary model, a cookie or session token can be scoped too broadly and end up valid across unrelated tenants. That makes tenancy design part of access control, not merely naming or hosting structure.
Why shared subdomains turn tenant boundaries into an access-control problem
Shared subdomains matter because they collapse separate tenants into a single browser trust context unless the application deliberately creates one. The real issue is not the hostname itself, but whether the platform can consistently prove which tenant a request belongs to before any cookie, session, or cached state is accepted.
A browser will happily send scoped state to any host that matches the cookie rules you set, so a weak tenant model can turn a naming convenience into cross-tenant reach. If tenancy is not enforced with a verified tenant context at every request, the platform starts relying on assumptions that the browser does not understand.
That is why multi-tenant design has to treat tenant isolation as part of authorization, not just DNS, routing, or branding. A shared subdomain can be safe only when the app layers explicit tenant checks, narrow cookie scope, and defensive session handling on top of it.
Where shared subdomains most often fail
The most common failure mode is overscoped session state. If a cookie is valid across multiple tenants, any defect in tenant resolution can let one tenant’s authenticated browser session be reused where it should not be accepted, especially when the app infers tenancy from subdomain, headers, or downstream defaults instead of binding it to a verified claim.
Another failure pattern is inconsistent tenant enforcement across layers. Login, API calls, background jobs, caches, and admin paths may each make different assumptions about tenant identity, so a request that is correctly isolated in one component can still leak or mutate data in another.
- Cross-tenant access usually appears when the app trusts the request path or host more than the user’s actual tenant membership.
- Shared caches can replay tenant-sensitive responses unless cache keys include tenant context.
- Logout and session revocation fail open when token scope is broader than the tenant boundary.
- Test coverage often misses these bugs because unit tests verify login, not tenant switching or hostile host-header combinations.
For platforms that also expose APIs, the same pattern shows up as broken object-level authorization, where the object lookup succeeds but the tenant ownership check does not. NHIMG’s OWASP API Top 10 API1 Broken Object Level Authorization Guide is useful here because it frames cross-tenant exposure as an authorization failure, not just an API bug.
How to design shared subdomains without turning them into a tenant leak
The safer model is to treat the subdomain as a routing hint, not as proof of trust. The application should establish tenant context from an authoritative source, verify it against the authenticated principal, and reject any request where the tenant context and the identity context do not line up.
Cookie scope should be deliberately narrow, especially when tenants share a parent domain or a common session layer. If a token or session must be reused across multiple hosts, then the platform needs stronger binding controls, explicit audience checks, and clear session invalidation rules so that one tenant cannot inherit another tenant’s authenticated state.
Implementation detail matters as much as policy. NHIMG’s Multi-Tenant SaaS Architecture Security Guide and Multi-Tenant SaaS Authorisation and Tenant Isolation Guide both support the same practical point: tenant isolation has to be enforced in request handling, data access, and testing, not assumed from URL structure.
Where tenant separation is strong, the platform can still use shared infrastructure, but it must make tenant context explicit in database queries, caches, logs, and access checks. Where it is weak, the problem is not cosmetic, it is a structural authorization flaw that can expose data across tenant lines.
Risk and Threat Considerations
Shared subdomains raise the blast radius of a small configuration mistake. If tenant context is inferred rather than verified, a single cookie scope error, cache key mistake, or host-based routing flaw can expose multiple tenants at once, and that exposure may remain invisible until a user lands in the wrong tenant context.
Failure mechanism: The platform accepts browser state or request metadata as an implicit tenant signal, then reuses that state across unrelated tenants because the boundary is not bound to authenticated identity and object-level authorization.
Impact: Attackers or simply misrouted users can cross tenant boundaries, read or modify another tenant’s data, and persist access through sessions or cached state that were never meant to be shared.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Shared subdomains often fail as cross-tenant object access control. |
| Recommendation — Enforce tenant ownership checks on every object lookup and API response. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Tenant-scoped access should limit what a session can reach across hosts. |
| IA-5 — Authenticator Management | Broad session and cookie scope makes credential and token handling central. | |
| Recommendation — Restrict each tenant session to the minimum objects and actions it needs. Bind, rotate, and invalidate session and token material with narrow scope. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Tenant boundaries are an access control design problem in shared hosting. |
| Recommendation — Define and enforce tenant access rules for shared-domain environments. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Tenant isolation depends on verifying identity before authorizing tenant access. |
| Recommendation — Validate tenant context before allowing access to tenant data or functions. | ||
Practitioner Guidance
What to verify: Confirm that tenant identity is derived from a server-side authoritative source, not from hostnames alone, and that every data access path rechecks tenant ownership before returning results.
Common mistake: Treating cookie domain settings, subdomain naming, or single sign-on success as evidence of tenant isolation. Those controls may help the UX, but they do not prove the boundary is safe.
Practitioner takeaway: Shared subdomains are acceptable only when the platform can prove tenant context at every trust decision, because browser scoping rules do not understand organisational boundaries.
Related resources from NHI Mgmt Group
- Why do shared-schema multi-tenant systems create cross-customer risk?
- Why do shared software platforms create outsized security risk?
- Why do shared physical keys and reusable MFA methods create security and operational risk in multi-user facilities?
- Why do shared PostgreSQL databases create higher access-control risk for multi-tenant SaaS applications?