Multi-tenant isolation testing: how to check that tenants cannot see each other

Multi-tenant isolation testing checks that one customer of a SaaS product (a tenant) cannot read or change another tenant's data. Testers create two tenants with known test data, run every feature from each, and look for any cross-tenant effect.

A tenant leak is a serious SaaS finding, because it exposes one customer's data to another. It is a form of broken access control, A01:2025 in the OWASP Top 10, and a tenant-level version of IDOR. This page gives the matrix we use, a sample request and fixes.

How do testers set up a two-tenant test?#

Set up two tenants that are as alike as possible. Use the same plan, the same roles and the same feature flags, so that any difference in results points to a flaw, not to a setting.

1. Create Tenant A and Tenant B. Mark both as test accounts.
2. In each tenant, create a member and an admin.
3. In every feature, create a known record. Give each record a distinct, readable marker, such as A-note-001 and B-note-001.
4. Record every ID the app returns: users, projects, files, invoices, API keys, webhooks.
5. Get the system owner's written authorization before testing.

The markers make a leak easy to prove: if tenant A's response contains B-note-001, the leak needs no interpretation.

What is the two-tenant test matrix?#

Run each row from tenant A's member, tenant A's admin and an anonymous caller. Target tenant B's data each time.

How does a tenant leak look in a request?#

A tenant leak often appears when a request carries a tenant identifier that the server trusts.

GET /api/v1/projects HTTP/1.1
Host: api.harbor-notes.example.com
Authorization: Bearer <token-of-tenant-A-member>
X-Tenant-Id: tenant-b

HTTP/1.1 200 OK
Content-Type: application/json

{"items": [{"id": "p-300", "name": "B-project-001", "tenant": "tenant-b"}]}

The tester then runs the controls: tenant A's own ID, a nonexistent tenant ID, B's header with no token, and B's header with a token for a different, valid tenant. Controls that held go in the report.

Why do tenant leaks hide in caches, search and files?#

Shared layers outside the main query path hide tenant leaks. App code may filter by tenant on the main table and forget the same filter elsewhere.

• Caches. A cache key made from the URL alone (without tenant or user) can serve one tenant's page to another. Test by requesting the same path from both tenants and comparing bodies.
• Search indexes. The index may hold all tenants' documents, with the filter applied only in some query types. Test with search, autocomplete and "similar items" features.
• File storage. Files may live in one bucket with guessable or leaked keys. Test whether a file URL works without a token, or with another tenant's token.
• Background jobs and exports. A job may run with a service identity that has access to all tenants. Test by passing another tenant's resource ID.
• Logs and audit views. An activity feed may include other tenants' events.

How do testers prove cross-tenant writes?#

Writes need the same care as reads. Change only a test-owned record in tenant B, then read it back through B's session. A 200 OK from the write request is not proof, while the read-back from B shows whether the change took effect.

For destructive actions such as delete or role change, use a throwaway record created for the test. State this in the scope. The report should say which test records the testers changed.

How do teams fix tenant isolation flaws?#

Enforce the tenant at the data layer, not in each handler. Take the tenant from the verified session or token, never from a header, body field or URL that the client controls.

For row-level security in PostgreSQL, a policy filters rows by a setting that the app sets per request from the session (see the PostgreSQL row security docs). A sketch:

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

The app sets app.tenant_id from the authenticated session at the start of each request. The app's database role must not own the table or have the BYPASSRLS attribute, because table owners and such roles skip the policy unless forced.

For the other layers, include the tenant ID in every cache key, search filter, file path and job payload, and give background workers a per-tenant scope. Add a build test that runs two tenants through each new route.

What should you do next?#

Run the matrix on every release that adds a new object type, export or integration. Our SaaS penetration testing service uses this two-tenant method, with written scope and evidence for each finding. The IDOR basics are in the IDOR testing guide. For the API risk list, see the OWASP API Security Top 10 guide. Billing and entitlement flaws are a business logic topic: see business logic vulnerabilities.

What does a tenant isolation finding look like?#

A finding names the shared layer that failed and shows the marker that crossed the boundary. This illustrative write-up shows the shape.

What evidence should you keep?#

Keep evidence that lets someone else replay the test.

• Request and response pairs, with timestamps, for tenant A and tenant B.
• The marker that crossed the boundary.
• The read-back from the owning tenant for any write.
• The control results.
• A note of which test records were changed or deleted.

Our methodology page describes the evidence labels we use. Put inferred causes on their own line, as the sample does.