Public suffix boundaries are straining under multi-tenant growth

At a glance

What this is: NHI Mgmt Group's analysis, drawing on ngrok's blog post: Public suffix boundaries are central to browser cookie scoping and multi-tenant isolation, but maintainer workload and list growth are making that governance model harder to sustain.

Why it matters: This matters because identity and access decisions often depend on browser-scoped trust boundaries, and weak boundary governance can turn tenant separation into shared-session risk.

Context

A public suffix is the boundary browsers use to decide where one registrable domain ends and another begins, which is why cookie scope, tenant separation, and session sharing do not rely on domain spelling alone. In practice, that boundary is a governance control for shared platforms, not just a browser implementation detail.

For multi-tenant services, the control plane is not only authentication and authorisation, but also where browser-scoped trust begins and ends. When a platform shares infrastructure beneath a public suffix, it needs a reliable way to prevent one tenant’s session or cookie scope from reaching another tenant’s boundary.

Key questions

Q: What breaks when tenant isolation depends on browser cookie boundaries?

A: When tenant isolation depends on browser cookie boundaries, a mis-scoped cookie can cross from one application into another and expose a session to the wrong tenant. The result is not just a browser quirk. It is a boundary failure that can turn shared infrastructure into shared trust, which is why scope checks must be designed as a control, not assumed as a default.

Q: Why do shared subdomains create security risk in multi-tenant platforms?

A: 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.

Q: How do teams know whether a public boundary registry is still trustworthy?

A: A boundary registry is trustworthy only if it stays accurate enough for browsers to enforce isolation consistently. Warning signs include slow review queues, disputed submissions, and pressure to use the list for purposes beyond tenant separation. Once the registry becomes a general-purpose gatekeeper, its security value starts to depend on human triage capacity rather than clean boundary semantics.

Q: Should security teams rely on DNS to prove tenant separation?

A: No. DNS shows where names resolve, not whether two names belong to the same trust domain or to unrelated tenants. Security teams should use DNS as a routing mechanism and an explicit boundary model for isolation decisions, because browser-scoped trust requires more than delegated naming structure.

Technical breakdown

How browsers use the public suffix boundary for cookie scope

Browsers compare a cookie’s requested Domain attribute against the Public Suffix List to decide whether the scope is allowed. If the requested domain sits at or above the public suffix boundary, the cookie is rejected because it could be shared across unrelated tenants. This is not a general DNS rule. It is an application-layer trust decision built on a curated registry of shared boundaries. The mechanism matters because session cookies are often the practical control that preserves authenticated state across subdomains. If that scope is wrong, the browser can turn tenant separation into cross-tenant exposure. See the Same-Origin Policy and Browser Security Model Guide.

Practical implication: Treat cookie scope as a boundary control, not a convenience setting, and test whether subdomains can set shared cookies outside intended tenant lines.

Why DNS alone cannot define tenant boundaries

DNS can tell a client where a name resolves, but it does not tell the browser whether two names are operated by the same organisation or by unrelated tenants. That distinction is the core problem the Public Suffix List addresses. Shared hosting, custom subdomains, and delegated tenant namespaces all look similar in DNS answers, yet they have very different trust implications. Without a separate boundary registry, browsers would have to guess where one tenant ends and another begins, which would make cookie handling and related browser decisions unsafe by default. The list exists because names are not trust boundaries on their own.

Practical implication: Do not assume DNS ownership or zone structure proves tenancy isolation, because browser trust decisions need an explicit boundary model.

Why shared-domain platforms create boundary governance pressure

Multi-tenant platforms rely on the PSL because they hand out subdomains to many unrelated customers under the same parent namespace. That makes every new entry a governance decision about whether the platform is a shared boundary or a single trust domain. The article shows that this is now creating operational strain, because volunteers must review and reject a growing volume of requests while the ecosystem keeps expanding. The technical problem is not just adding entries. It is keeping a human-governed boundary registry accurate enough that browsers can enforce tenant isolation consistently.

Practical implication: Build your platform assuming boundary registration is a dependency you do not control, and minimise reliance on discretionary list changes.

Threat narrative

Attacker objective: The attacker objective is to reuse a session or trust token across a tenant boundary and impersonate another user or service.

1. Entry occurs when a platform lets multiple unrelated tenants operate beneath a shared domain boundary without a reliable browser-enforced isolation rule.
2. Credential or session abuse follows if one tenant can scope cookies too broadly and another tenant can read or receive them.
3. Escalation happens when the shared cookie or session token is accepted across a boundary that should have separated tenants.
4. Impact is cross-tenant session hijack or unintended trust expansion across independent applications.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public suffix governance is a boundary-control problem, not a browser footnote. The article shows that cookie scoping depends on a curated list because DNS naming alone cannot express tenant trust. That means the security boundary is partly social and operational, not purely technical. Practitioners should treat boundary registries as part of the control fabric, especially where customer subdomains and shared infrastructure coexist.

Multi-tenant isolation fails when platform growth outpaces boundary review capacity. The maintainers’ workload is itself a security signal: a trust boundary that depends on a small volunteer group becomes fragile as demand rises. That fragility matters for SaaS, hosting, and identity-adjacent platforms that use subdomains to separate customers. The governance lesson is simple: if isolation depends on external review capacity, the control is already under strain.

Cookie scope is a concrete example of the cross-tenant trust gap. A browser will accept a cookie only when the requested scope sits below the public suffix, which prevents one tenant from quietly extending session state into another tenant’s namespace. That is exactly the kind of isolation rule that browser security model thinking requires. Practitioners should recognise that shared-domain architecture makes session governance part of tenancy design, not an afterthought.

The hard part is not adding entries, it is proving tenancy legitimacy. The debate over making the list harder or easier to join reflects a deeper problem: a public boundary registry must decide who qualifies, but it cannot verify trust intent perfectly. That creates an operational bottleneck where security depends on judgement, not just syntax. Teams should design for the possibility that boundary registration is slow, contested, or unavailable.

AI intensifies the maintenance burden without solving the trust question. The article suggests AI can flood maintainers with polished requests, but it cannot establish whether a service belongs on the list. That distinction matters for identity governance because automation can draft submissions, yet it cannot certify organisational trust or tenancy separation. Practitioners should not confuse machine-generated compliance with actual boundary assurance.

Read next: Multi-Tenant SaaS Architecture Security Guide

What this signals

Boundary registries are becoming a governance dependency for shared platforms. As more services hand out subdomains to independent customers, the question shifts from whether isolation is possible to how much operational friction a human-reviewed boundary model can absorb. That pressure should push platform owners to minimise reliance on discretionary registration and design tenancy separation so it fails closed when the boundary cannot be verified.

Tenant isolation will increasingly be judged at the browser boundary, not just in application logic. When session scope, cookie acceptance, and shared hosting intersect, browser rules become part of the identity and access story. Teams that ignore that layer will keep discovering that apparently simple subdomain choices create long-lived governance debt.

For practitioners

• Review tenant-boundary assumptions in shared-domain designs Map every customer-facing subdomain and identify where browser cookie scope, session sharing, and tenant isolation rely on a public suffix boundary rather than a dedicated domain.
• Test for cross-tenant cookie acceptance Verify whether any application can set a cookie that reaches beyond its intended tenant namespace, especially on shared hosting and delegated subdomain models.
• Treat boundary registration as an external dependency Build operational plans that do not assume a new public suffix entry will arrive quickly, because tenant isolation should not depend on a volunteer review queue.
• Separate custom-domain strategy from default-domain isolation Preserve isolation for default subdomains even when customers later configure custom domains, so early tenancy choices do not become permanent trust shortcuts.
• Document who owns trust-boundary decisions Assign clear internal ownership for subdomain tenancy, cookie scope policy, and escalation when a platform request depends on a browser boundary decision.

Key takeaways

• Shared-domain platforms depend on browser-enforced boundaries, so cookie scope is a security control rather than a convenience feature.
• The Public Suffix List exists because DNS cannot tell browsers where one tenant’s trust ends and another’s begins.
• Platform teams should design tenancy isolation so it does not depend on a slow or contested external registration process.

Related NHI Mgmt Group resources: Same-Origin Policy and Browser Security Model Guide · Multi-Tenant SaaS Architecture Security Guide · Password Manager Vault Breach Response Playbook

Key terms

• Public Suffix List: A curated registry of domain boundary rules that tells browsers and other software where a registrable domain begins. It exists because DNS labels alone do not reveal whether subdomains belong to one organisation or to many unrelated tenants, which makes it essential for cookie scope and other trust decisions.
• Public Suffix Domain: A Public Suffix Domain is a DNS boundary that marks where one party's namespace ends and another party's begins. RFC 9989 uses this idea to make delegated boundaries explicit, so receivers can apply policy based on declared ownership rather than inferred structure.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
• Cookie Scope: Cookie scope is the set of domains and subdomains on which a browser will send a stored cookie. If scoped too broadly, a session identifier can travel farther than intended and create cross-tenant exposure. Correct scope is a security control, not just a deployment detail.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course when your programme needs stronger control over identity boundaries and lifecycle governance.