Direct answer
Tenant isolation testing verifies that one customer's users and services cannot reach another customer's protected data or actions. Create two dedicated test tenants and trace the tenant boundary through requests, storage, caches, exports, and background jobs.
Define tenant ownership and shared data
Some data is tenant-owned while other data is deliberately global, such as a public template catalog. Classify the record types and allowed platform operations before testing. A support administrator with explicit cross-tenant permission is a different policy case from a regular tenant member.
- Create distinct fixture tenants and known records in each.
- Identify legitimate shared objects and platform roles.
- Document service identities that are intentionally cross-tenant.
Verify the selected tenant
A tenant identifier supplied by a client should select a context only when the authenticated caller is allowed to use it. Review how that context reaches data access and permission decisions. Changing a tenant selector must not silently change the caller's authority.
Reference: OWASP Multi Tenant Security Cheat Sheet.
Follow data beyond the main API
A correctly scoped query can still feed an incorrectly shared cache or export. Read the same fixture route from both tenants, then inspect generated files and delayed job results. If a job runs after a member is removed, compare its authorization behavior with the product's stated policy.
- Cover cache hits as well as fresh data reads.
- Include attachments, thumbnails, exports, and download links.
- Record which tenant receives each background job's result.
Retest the complete isolation boundary
Repairing one endpoint does not establish that storage or worker boundaries are correct. Add negative cross-tenant tests and positive same-tenant controls at the affected layer. Recheck member removal and resource deletion when either changes the expected access.
Reference: OWASP Multi Tenant Security Cheat Sheet.
Assessment limits
Two tenants exercise selected boundaries rather than every customer configuration. Platform support access, shared catalogs, and service accounts require explicit policy. Infrastructure isolation and backup restoration need their own environment-level evidence.
Frequently asked questions
Does a separate workspace ID prove tenant isolation?
No. The server must bind tenant selection to an authorized identity and preserve the boundary across the components that handle tenant-owned data.
Which SaaS routes are often missed in a test?
Generated exports, download URLs, cached responses, and delayed jobs can use access paths different from the main object route. Include those paths when the product supports them.
Is every cross-tenant response a vulnerability?
Evaluate the documented policy. Deliberately public data or an explicitly authorized platform operation can be valid; regular users accessing another tenant's protected data is a different case.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.