Multi-tenant application isolation
Enforce verified tenant context across APIs, storage, search, caches, jobs, and exports, including changes in membership and shared resource consumption.
What it means
Multi-tenant isolation keeps one customer's identities, resources, and data separate from another's within shared infrastructure. Tenant context must come from a verified relationship rather than an arbitrary caller-supplied value. Isolation also applies to caches, exports, background jobs, search, and resource consumption.
A practical example
A service verifies the caller's membership before choosing the tenant used for data queries. It includes tenant identity in relevant cache and job boundaries and tests that one customer's export cannot retrieve another customer's objects.
What to check
Trace tenant context through every data path, enforce resource-specific access, and test cross-tenant operations with separate accounts. Review shared caches and asynchronous processing as carefully as the main API.
A common pitfall
Query parameterization prevents query syntax injection but does not enforce tenant ownership. A safely bound tenant identifier may still select the wrong customer's data.
Think it through
Can an API trust a tenant header because the frontend set it?
Answer: No. It must verify the caller's relationship to that tenant before applying the context.
Trace a tenant beyond the first request
Imagine a fictional platform serves two training organizations. An authenticated user belongs to one organization, but a request includes a header naming the other. The server must verify that relationship before selecting the tenant context.
Once selected, the context has to survive database queries, caches, jobs, and exports. A correct API check can be undermined if a background worker later loads an object without the same boundary.
Verified tenant context must follow requests, background work, and resource access throughout a shared platform. Open full-size diagram ↗
Shared infrastructure has hidden reuse paths
Suppose the platform caches a report using only its numeric report identifier. If identifiers overlap between organizations, the cache could return the wrong content even when the underlying query is scoped correctly. Include the relevant isolation context in the reuse decision.
Search indexes and derived summaries deserve the same review. Data being technically searchable does not establish that every caller may retrieve it. Permission updates and deletion also need to propagate appropriately.
Isolation includes availability effects
A tenant that launches excessive expensive work can affect others through shared queues or workers. Resource limits and scheduling should reflect the service's promised separation as well as its data permissions.
For an authorized lab exercise, create two tenants and separate test accounts. Follow one report from request through job creation, storage, and download. At each stage, identify where membership and object ownership are enforced. Then change the account's membership and test access again. The result should demonstrate isolation throughout the data lifecycle, rather than relying on a safely parameterized query or a tenant label supplied by the frontend.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Multi Tenant Security