Cross-tenant Leakage

1. A green API decision does not prove tenant isolation

A multi-tenant request can be correctly authorized for Tenant A at the API and still cross an unscoped database query, shared cache key, incomplete queue envelope, or wrong object-storage prefix that exposes Tenant B data. This lesson focuses on the gap between initial authorization and preservation of tenant context through the full path. OWASP lists cross-tenant data leakage and broken tenant isolation as key multi-tenant risks and recommends deriving tenant context from server-verified identity and propagating that context to downstream components. [OWASP-MULTITENANT]

2. A tenant ID is a selector, not authorization evidence

A tenant_id in a header, parameter, or payload only selects a tenant. It does not prove the caller may act there. Valid context must be bound to an authenticated principal and current membership or service authorization. If a downstream component replaces verified context with untrusted input, isolation can fail even when the initial middleware is correct. [OWASP-MULTITENANT]

3. Define isolation as a negative invariant

At every shared boundary, ask the same question: can Tenant A read, write, receive, or cause a side effect against Tenant B state? The acceptable answer is no, backed by direct evidence. Merely having a tenant field in a schema, cache key, or log is insufficient; enforcement must be observable on the exercised path.

4. The database is only one boundary

A query predicate or RLS policy may correctly isolate the database while cache, object storage, queues, background jobs, or audit/read APIs still leak state. Diagnosis therefore needs a boundary map and independent state for each layer. One passing query is not full recovery.

5. Cache keys must carry every context dimension that changes the result

OWASP recommends including the tenant identifier in cache keys for tenant-varying data and warns that cache separation does not replace authorization. [OWASP-MULTITENANT] If two tenants share a key such as user:42, a cache hit can bypass an otherwise correct database query. Containment should invalidate or partition the unsafe shared entries.

6. Queues and background jobs are authorization boundaries too

Asynchronous work should not treat a tenant string as self-authenticating context. The producer path must establish verified context and the consumer must enforce authorization for the operation it performs. OWASP explicitly recommends carrying verified tenant context through tenant-scoped asynchronous work and re-establishing authorization at the consumer. [OWASP-MULTITENANT]

7. Object storage needs an enforceable tenant boundary

A path such as tenant-a/... is only a convention unless policy or the access layer authorizes the exact object and operation. OWASP recommends classifying objects by scope, partitioning tenant-owned objects with a tenant-aware key/bucket/policy, and authorizing exact access before serving or signing it. [OWASP-MULTITENANT]

8. Tenant Isolation Breach Evidence Record v1

The owned artifact records Actor Tenant, Resource Tenant, Verified Tenant Context, API Decision, DB Scope, Cache Namespace, Queue Context, Storage Prefix, Exposure Observation, First Failed Boundary, Containment, Negative Isolation Test, Closure State, and Residual Shared State. Each decisive cell must be observed, authority-backed, inferred, or explicitly UNKNOWN.

9. Separate the first failed boundary from the final symptom

Seeing Tenant B data in a response identifies the symptom, not the first failed control. The cause may be cache, query scope, queue propagation, or storage. Use one-boundary-at-a-time contrast probes. If the evidence cannot locate the first failure, keep the classification OPEN/UNRESOLVED rather than guessing.

10. Use a negative control to reject alternatives

If cache is suspected, rerun with cache bypass or a correct namespace while holding the rest of the path stable. If leakage disappears, competing explanations weaken. That evidence still applies only to the bounded fixture and must not be generalized into a claim that the entire service is secure.

11. Containment is not recovery

Containment may fail-close a route, invalidate cache, pause a queue consumer, or block object release. These actions reduce blast radius but do not necessarily repair the failed boundary. Recovery requires changing the failed control and rerunning an independent negative isolation test that demonstrates the cross-tenant read or write no longer occurs.

12. Closure must cover every shared boundary touched by the path

After fixing cache, recheck database, queue, storage, and any other shared layer used by the request. OWASP likewise frames isolation across multiple boundaries including database, cache/session, API, file storage, and audit. [OWASP-MULTITENANT] Closure in this lesson requires negative isolation evidence for the bounded path or an explicit unresolved review state.

13. Transfer: the failure can move to another boundary

In the changed-context fixture, the cache namespace is repaired while an object-storage prefix becomes wrong. Copying the prior label cache leak fails transfer. Rebuild the evidence record from the mutated fixture and identify the new first failed boundary.

14. Lab: eight fixtures and 64 assertions

The lab is entirely local and synthetic: two fake tenants, fake records, and deterministic state cards. The eight cases cover a safe baseline, database leak, cache leak, queue leak, storage leak, blocked cross-tenant attempt, incomplete evidence, and a transfer mutation. The administrative evaluator checks eight outputs per case for 64 assertions. No real target, credential, or customer data is used.

15. Exit checklist and claim boundary

Before exit, you must be able to name the verified tenant context; test database, cache, queue, and storage independently; reject at least one alternative with negative evidence; preserve UNKNOWN; separate containment from closure; rebuild the transfer fixture from fresh evidence; and state that success proves only isolation of the synthetic lesson fixture, not complete security of a real multi-tenant service.