SaaS Tenant Isolation: A Practical Checklist Before You Launch

In a multi-tenant product, tenant isolation is a product requirement, not just a database choice. Every request must have a trustworthy answer to one question: which organisation is allowed to access this record?

OWASP calls broken object-level authorization a common API risk because an attacker may alter an object identifier in a path, query or payload to access data they should not see. Their guidance is direct: every endpoint that accepts an object identifier should verify permission for the requested record. Read the OWASP guidance.

Choose the isolation model deliberately

There is no universally correct tenancy model.

| Model | Useful when | Trade-off | | --- | --- | --- | | Database per tenant | Customers require strong physical separation or bespoke operations. | Higher operational overhead. | | Schema per tenant | A controlled set of tenants need clear logical separation. | Migrations and reporting become more complex. | | Shared schema with tenant key | Many tenants share the same product and operations model. | Every query and policy must enforce the tenant boundary. |

For a shared model, treat the tenant identifier as part of the data model, not a UI convenience. Never accept it from the browser as the sole source of truth.

The launch checklist

1. Resolve tenant context on the server

Derive tenant context from an authenticated session, verified domain, membership record or explicit server-side selection. Record it once per request and pass it through the application deliberately.

2. Enforce access at more than one layer

Application checks improve readability, but they should not be the last line of defence. Use database policies, query scopes or equivalent controls where your data platform supports them. A background worker, admin tool or newly added endpoint should not accidentally bypass the rule.

3. Authorize the object, not only the role

“User is an admin” is not enough when an object belongs to another tenant. Before reading, updating or deleting a record, verify both the actor’s role and the record’s tenant relationship.

4. Test negative paths

For every important endpoint, write a test in which a user from tenant A tries to access an object from tenant B. Test reads, edits, deletes, file downloads, exports and webhook-triggered work—not only the visible screen.

5. Keep audit evidence for sensitive actions

For membership, role, billing and data-export actions, log the actor, tenant, action, target, time and result. Logs should help an operator investigate a problem without becoming a second uncontrolled data store.

The practical test before release

Create two test tenants with recognisably different data. Sign in as a non-admin user in tenant A, then try every identifier-changing path you can find: URL parameters, API calls, file links, export requests and background-job payloads. The expected result is a consistent denial—not an empty page that merely hides the data.

Building this boundary early is much less expensive than retrofitting it after customers depend on the product. For help designing a secure multi-tenant foundation, see Gavior’s SaaS development services.