Multi-Tenant SaaS: Proving One Customer Cannot See Another
Tenant isolation is the single promise a multi-tenant platform makes, and it is the one your customers will ask you to evidence during due diligence. The main request path is usually well protected because it gets the most attention. Isolation tends to fail somewhere quieter: a cache, an export, a search index or a job that runs at two in the morning.
Where the tenant identifier comes from
Everything rests on this. The tenant must be derived from the authenticated session, never from a parameter the client supplies, and the check must happen on the server for every request. Systems that accept a tenant identifier in a header or body, even alongside a session, are one missing validation away from cross-tenant access. NIST’s guidance on microservice security strategies in SP 800-204 makes the same argument about propagating identity rather than trusting a caller’s assertion, and it applies just as much inside a monolith.
See also: The Environmental Impact of Modern Technology
The places isolation quietly breaks
Caches are the classic example: a response cached under a key that omits the tenant will be served to whoever asks next. Background jobs are another, because they run without a user session and often query across all tenants by design, so a filter mistake exposes everything at once. Then there are exports and reports, which frequently use a different code path from the interface, and file storage where objects are addressed by identifier rather than checked against ownership. Notification emails deserve a look as well, because a template rendered with the wrong context posts one customer’s data to another. Search indexes deserve their own review, since a shared index with tenant filtering applied at query time is one forgotten filter from a serious incident.
“Test the administrative features hardest. Nearly every platform has an impersonation function so support can see what a customer sees, and it is often protected by a role check written years ago and never revisited. If that function can be reached with a manipulated request, you have built a cross-tenant vulnerability into the product deliberately and then forgotten to lock the door.”
William Fieldhouse, Director, Aardwolf Security Ltd
How isolation is actually tested
With two accounts in two tenants and a great deal of patience. The tester works through every function as tenant A, records the identifiers involved, then repeats each request as tenant B substituting A’s identifiers. Object identifiers, file references, report jobs, webhook configurations and notification settings all get the same treatment. Randomised identifiers make guessing harder and prove nothing about authorisation, so a system relying on unguessable references rather than ownership checks will fail this exercise as soon as an identifier leaks.
Evidence customers will accept
Enterprise buyers increasingly ask for proof rather than a policy statement. A report naming tenant isolation as a tested objective, with a description of the method and the result, answers the question in one document and shortens a security review considerably. SaaS penetration testing covers the interface and the platform behaviour, while API security testing services cover the endpoints that partners and mobile clients use, which are often where the older, less protected paths remain.
Frequently asked questions about tenant isolation
These questions come up during customer security reviews.
Is a database per tenant safer?
It reduces the impact of a query mistake and brings its own operational cost and complexity. Plenty of secure platforms use a shared database with strict row-level controls, so the model matters less than the discipline applied to every code path.
How often should isolation be retested?
At least annually, and after any significant change to data access, caching or reporting. Those three areas produce most of the regressions we see in platforms that were previously clean.
