Trace one question through your diagram: at every step, how does the system know which tenant this is, and what happens if that knowledge is missing or wrong? The usual weak spots are request context, the database, caches, background jobs and shared capacity. OWASP's multi-tenant guidance covers each.
Mark the tenant context path
Draw the request from client to API to database, then add the cache, the queue and the workers. Colour or label every place the tenant ID is set, read or dropped. The gaps in that line are your threats.
Where tenants leak into each other
| Area | Threat | OWASP guidance |
|---|---|---|
| Request context | Client-supplied tenant ID trusted | Treat it as a selector only and confirm the caller's current membership in that tenant |
| Database | Query runs without tenant filter | Use row level security, fail closed when context is missing, avoid superuser or bypass roles for tenant requests |
| Pooled connections | Tenant setting carries to the next request | Set context per transaction, not per session |
| Cache | Key lacks tenant, one tenant reads another's data | Include tenant ID in the key and authorize before reading protected cached data |
| Background jobs | Delayed job runs with the wrong or unverified tenant | Bind tenant context to the message and re-authorize at the consumer |
| Shared capacity | One tenant starves the rest | Add tenant as a rate limit dimension, including queues and database connections |
| Encryption | Shared key where isolation is required | Consider per-tenant keys when risk or compliance requires it |
Points that surprise teams
- An ORM filter is defense in depth only. Raw SQL, bulk operations and other session types need separate controls.
- A shared queue is not an isolation boundary by itself.
- Key separation in a cache does not replace authorization.
- Test with the same role, connection path and pooling mode as production, because privileged test connections hide real failures.
Write the tests from the threats
From the guidance, good tests include: for each protected table, cross-tenant access is denied and same-tenant access works; the request role lacks superuser and bypass attributes in deployed environments; two tenants over reused connections never see each other's context; and a restore for one tenant leaves the other absent. See also integration tests for tenant isolation.
Decide what to accept
Some isolation costs real money, such as separate cache instances or per-tenant keys. The model is where you decide which tenants or data classes justify them, and record who accepted the remaining risk.
Try it yourself
Click through it at your own pace, or open it full screen. Click through it and look at how API endpoints are probed, which is where cross-tenant tests end up.
Quick check
Is a tenant ID in the URL enough to isolate tenants?
No. Guidance says client-supplied identifiers are selectors only. The server must confirm the authenticated caller belongs to that tenant before using it.
Do background jobs need tenant checks?
Yes. The consumer should re-establish tenant context and re-authorize, especially for delayed work, because the original request is long gone.
A note on tooling
Isolation design is yours to model. Safeguard covers adjacent checks: SBOM and dependency scanning, reachability analysis and compliance evidence automation. Try the free scan.
Sources
Last reviewed: 19 October 2026.
