One customer seeing another customer's data is the failure that ends B2B relationships and triggers breach notifications. The API endpoints usually get this right because that is where the tests are. The leaks come from the paths nobody thinks of as user-facing, and they are consistent enough across products to be worth listing.
01Where isolation actually breaks
Background jobs are the most common culprit. A nightly report generator, a data export, a cache warmer or a search reindexer that queries without a tenant filter will happily process everything, and no request-scoped middleware is there to stop it because there is no request.
Search indexes are second. Documents from every tenant land in one index and the filter is applied at query time, which works until a query path forgets it - autocomplete, a suggestion endpoint, a related-items feature. Caches are third, where a key without the tenant id serves one tenant's data to another.
| Path | Why it leaks | Fix |
|---|---|---|
| Background jobs | No request context, filter omitted | Tenant id required in the job payload |
| Search index | Shared index, filter at query time | Filter enforced in a shared wrapper |
| Cache keys | Key lacks tenant id | Tenant id in every key, enforced by helper |
| Exports and reports | Bulk query bypasses normal path | Same access layer as the API |
| Webhooks | Payload built from an unscoped query | Scope at construction |
| Admin tooling | Deliberately unscoped, then reused | Separate code path entirely |
02Make the filter impossible to forget
Relying on every developer remembering a WHERE clause is a plan that fails on the first busy Friday. The mechanism has to be structural: row-level security in the database, or a data access layer that requires a tenant context and refuses to build a query without one.
Row-level security is the strongest option because it holds even when application code is wrong, including in ad hoc queries and background jobs. The cost is that it must be configured carefully and that a connection pool sharing sessions across tenants needs explicit handling.
03Choosing the isolation model
Shared schema with a tenant column is the default and scales well operationally. Schema per tenant gives stronger isolation and becomes painful past a few hundred tenants because migrations must run everywhere. Database per tenant is the strongest and the most expensive to operate.
Most products should start shared and move specific large or regulated tenants to dedicated databases when there is a concrete reason. Starting with database-per-tenant because it feels safer usually means operational overhead that the customer base does not yet justify.
| Model | Isolation | Operational cost | Fits |
|---|---|---|---|
| Shared schema, tenant column | Application-enforced | Lowest | Most SaaS |
| Shared schema plus RLS | Database-enforced | Low | Most SaaS, better default |
| Schema per tenant | Strong | Moderate, migrations multiply | Hundreds of tenants max |
| Database per tenant | Strongest | High | Regulated or very large tenants |
04Test it as an adversary, not as a user
Create two tenants with realistic data and then try to cross the boundary deliberately: manipulate identifiers in every endpoint, run every background job, trigger every export, query search directly, and inspect cache contents.
Automate the identifier manipulation as a test that runs in CI - for every resource endpoint, a request from tenant A for a tenant B object must return not-found rather than forbidden. Returning forbidden confirms the object exists, which is itself a small information leak.
05Detect it, because prevention is not certainty
Log the tenant context on every data access and alert when a query returns rows spanning multiple tenants outside of explicitly allowed admin paths. That detection catches the case your tests did not cover, which is by definition the case you did not think of.
It also matters for the aftermath. If a leak does occur, being able to establish exactly what was accessed and by whom is the difference between a bounded, honest disclosure and a worst-case assumption that you have to make because the logs cannot tell you.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer