Skip to content
Authreads

Multi-tenant architecture

How to test tenant isolation before a customer finds the gap

A practical test plan for cross-tenant data leaks: two-tenant fixtures, object-ID swapping, background jobs, caches, search indexes and exports.

The short answer

Test tenant isolation by running every API with two tenants' fixtures and attempting to read, modify and list tenant B's objects while authenticated as tenant A — then repeat for the paths that sit outside the request: background jobs, caches, search indexes, exports, webhooks and admin tools. Cross-tenant leaks are almost always in those secondary paths.

Sources last reviewed .

The core test

  1. Create two tenants with overlapping data — same email addresses, same object names — so a missing filter returns something plausible.
  2. For each endpoint, authenticate as A and request B's object IDs directly (OWASP API1, broken object-level authorization).
  3. Attempt list and search endpoints and assert no B data appears.
  4. Attempt writes, including partial updates and bulk operations, against B's objects.
  5. Make these tests generated from your route list, so new endpoints are covered by default.

Where leaks hide

  • Caches keyed without the tenant ID.
  • Background jobs that run without request context and query unfiltered.
  • Search indexes and analytics stores built outside the database's isolation.
  • CSV exports, reports and admin panels.
  • Connection pools that carry a tenant setting from one request to the next.

Test the guarantee, not only the code

If isolation is enforced by the database (row-level security), add a test that runs a deliberately unfiltered query as the application role and asserts it returns only the current tenant's rows. That test fails if someone later grants the role BYPASSRLS or makes it the table owner.

Building on any of this?

Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.