Testing Tenant Isolation in Multi-Tenant SaaS: A Practical Playbook

Tenant isolation is a correctness property, not just a security property. A bug that allows tenant A to see tenant B's data is also a bug that makes your product incorrect. Testing it requires deliberate test design: you must create data in one tenant context and verify it is invisible in another.

The Test Matrix

Cross-tenant GET requests

For every resource type in your API (users, organizations, API keys, logs, configurations), create a resource as tenant A and then attempt to retrieve it using tenant B's credentials. The expected result is a 404 (not a 403 — a 403 reveals the resource exists). Automate this test across every data-returning endpoint.

Enumeration attacks

Sequential numeric IDs allow enumeration. If tenant A's resource is at /api/orders/1001 and tenant B tries /api/orders/1000, 1002, 1003, they can enumerate whether resources exist in adjacent tenants. Use UUIDs for all resource IDs exposed in APIs.

Shared resource visibility

Some resources are intended to be shared: public API specs, documentation, marketplace listings. Audit your list of genuinely shared resources and confirm everything not on the list is tenant-scoped. The shared-resource list should be explicitly maintained, not derived from "whatever happens to work."

Write isolation

Test that tenant B cannot modify tenant A's data: PUT, PATCH, and DELETE requests using tenant B's credentials targeting tenant A's resource IDs. A successful modification is a critical isolation failure.

RLS as the Safety Net

Row-level security at the database layer catches isolation failures that application code misses. If your tenant isolation tests reveal a violation and RLS is enabled, the violation will return empty results rather than another tenant's data — still a bug, but a safe bug. Without RLS, the same application bug returns the other tenant's data.