For a SaaS application, the worst realistic finding is nearly always the same: a user of one customer reaching the data of another. Everything else - injection, misconfiguration, a stale dependency - matters, but cross-tenant access is the one that ends contracts and triggers breach notifications for every affected customer simultaneously.
That single fact should shape the whole test, and generic web application testing frequently does not.
Why single-account testing cannot find it
This is a structural point rather than a quality one. To find a tenant isolation failure, a tester needs an account in tenant A, an account in tenant B, and to systematically attempt to reach B from A. With credentials for only one tenant, the entire class is out of reach.
It gets worse with roles. A realistic SaaS product has several - owner, admin, member, read-only, perhaps a billing role and an external collaborator. Authorisation testing means attempting each boundary crossing: can a member do what an admin can, can a read-only user write, can a collaborator in tenant A see anything in tenant B. The number of pairs grows quickly, and this is exactly the work that gets trimmed when a scope is cut to fit a price.
Where cross-tenant leaks actually happen
Rarely in the user interface. The interface generally only offers what the current user is allowed to see, which is why clicking around produces a clean result and false confidence.
The leaks live in the API. An endpoint that accepts an object identifier and returns the object without checking which tenant owns it. A bulk export that filters by user but not by tenant. A webhook or a report generator running with elevated privileges and taking the tenant identifier from the request. A search index built across tenants with filtering applied at display time rather than at query time.
| Layer | Common cross-tenant failure |
|---|---|
| REST or GraphQL API | Object ID accepted without a tenant ownership check |
| Bulk export or reporting | Filtered by user, not by tenant |
| Search | Index shared across tenants, filtered too late |
| Background jobs | Tenant taken from request input, running with elevated rights |
| File storage | Predictable object paths, no ownership check on fetch |
If your test did not have credentials in two tenants, it did not test tenant isolation. It tested a web application that happens to be multi-tenant, which is a different and much easier thing to pass.
What SaaS-specific testing should cover
Beyond the standard application surface, four things deserve explicit scope.
Tenant isolation across every data type and every entry point, driven from real accounts in separate tenants.
Role boundaries within a tenant, tested pairwise rather than sampled.
Provisioning and invitation flows. Inviting a user, accepting an invitation, changing a role, and removing access. Removal is the one that fails quietly: a revoked user whose session or API token keeps working is a common and serious finding.
Integrations and webhooks. Anything that carries a tenant identifier across a trust boundary, especially where a third party can influence it.
The commercial reason to get this right
SaaS companies mostly commission their first test because an enterprise prospect sent a security questionnaire. That is a reasonable trigger, and it creates a specific failure mode: buying the cheapest artefact that answers the questionnaire. We cover the broader timing question in when a startup needs a penetration test.
The buyer on the other side is increasingly sophisticated. Their security team - usually working from a SOC 2 or ISO 27001 checklist - knows the difference between a report that says "web application tested" and one that shows tenant isolation was attempted from a second tenant and held. The second one closes deals; the first one invites follow-up questions you would rather not receive. For cloud-specific controls, see the ISO 27017 and 27018 cloud controls.
If you want to see the reporting standard rather than take our word for it, our published research is written to the same bar, and the services page sets out what a SaaS engagement includes.