Check tenant isolation in a SaaS application

Define the customer context first

A tenant is a separate customer context in your application. It need not be one person or always an entire company. Define which data belongs together, who can be a member and which tasks each role may perform there. One user account can have several memberships; signing in alone does not select an authorised data scope.

Microsoft distinguishes a logical tenant from a technical deployment. A dedicated database and shared tables create different operational and access-control requirements. Neither option replaces checking every intended access path.

A test plan with two fictional customer contexts

Plan the following cases with synthetic data in a separate test environment. These are expected results, not a completed security test. The contexts are named TA and TB. Job SV-12 belongs to TA; job SV-41 belongs to TB. Each test account has the intended job permissions only in its own context.

Check data and actual changes on the server. A hidden button does not demonstrate isolation. Also use a known object identifier from another context: a hard-to-guess identifier must not be the only access barrier.

Carry the boundary through the whole workflow

OWASP calls for server-verified tenant context and appropriate authorisation. Context identifiers sent by a client are selectors, not permissions. Check current membership, the permitted action and ownership of the target object. If required context is missing, the application must not fall back to an unrestricted query.

Include attachments, tenant-dependent cache keys, exports and delayed processing. Background jobs need trustworthy propagation of context and authorisation, with appropriate checks during processing. Define how rights revoked in the meantime are handled.

Public, global content does not need an artificial tenant requirement. Cross-context platform tasks do need an identity explicitly authorised for them and traceable access. Record the expected result, actual finding and correction separately for each case. Repeat affected checks when access paths or roles change.

Sources

• OWASP: Multi-tenant security

• Microsoft: Tenancy models