Cross-Tenant Data Leakage
Cross-tenant leakage occurs when a multi-tenant system returns or exposes data belonging to a different tenant, the canonical SaaS failure where isolation breaks at the data layer rather than the.
Definition
Cross-tenant leakage is the exposure of one tenant data to another in a shared system, caused by missing tenant scoping in queries, cache key collisions, or log injection that spans tenants — the isolation boundary fails at the data access rather than the authentication gate.
Context and scope
Applied in multi-tenant SaaS, shared databases, and any system where logical isolation replaces physical separation between customers.
Common misconceptions
- Auth checks at the API prevent leakage — the data layer query must also scope by tenant, because a missed filter returns rows the API would have authorized
- Tenant IDs in URLs are sufficient — the server must bind the resource tenant to the authenticated session tenant, not to a client-supplied parameter
Anti-patterns
- Caching by resource ID without a tenant key, so tenant A request populates a cache entry served to tenant B
- Querying with a tenant filter that the ORM can silently drop when the relation is eager-loaded without a join condition
Related concepts
Authoritative source
What it is
Cross-tenant leakage is the exposure of one tenant data to another in a shared system, caused by missing tenant scoping in queries, cache key collisions, or log injection that spans tenants — the isolation boundary fails at the data access rather than the authentication gate. Applied in multi-tenant SaaS, shared databases, and any system where logical isolation replaces physical separation between customers. The threat model determines which controls apply: preventive controls block exploits, detective controls surface violations, and corrective controls restore integrity after an incident.
How it works
Effective implementations layer controls so that no single bypass compromises the asset. Verification happens at trust boundaries, not just at the perimeter. Cryptographic primitives are selected for the concrete property needed — unforgeability, indistinguishability, or non-malleability — and never composed ad hoc. Failure modes fail closed: a verification error denies rather than allows.
When to enforce and pitfalls
Enforce wherever an attacker can influence input that crosses a trust boundary. Common pitfalls include treating obfuscation as a control, relying on secrecy of the algorithm rather than the key, and auditing the happy path while ignoring error-handling branches where bypasses often hide. Rate-limit and log every verification attempt so brute-force and oracle attacks become visible.