SaaS tenant isolation: what a security review should test

Define ownership before writing tests

Create two synthetic organizations with users, administrators, and records that exercise real workflows. Describe which resources are shared, which are tenant-owned, and which operations intentionally cross organizations. Without that definition, an unexpected result can be mistaken for either a feature or a vulnerability.

Include lifecycle events such as invitations, organization switching, role removal, offboarding, and account recovery. A boundary that works when an account is created may fail after membership changes if permissions, sessions, or background jobs retain stale context.

References: [1] OWASP, [2] OWASP

Review the data access boundary

Check the server-side decision linking a verified caller to the organization and object being accessed. Do not treat a caller-supplied tenant value or an unguessable identifier as proof of permission. Object reads, updates, deletes, and exports may reach different code paths and require separate checks.

Review direct object access alongside list and search behavior. A filtered list can look correct while a download or export path bypasses the same ownership rule. Where database isolation is part of the design, confirm how application identities, connection context, and privileged maintenance work interact with it.

References: [3] OWASP, [1] OWASP

Follow ownership outside the database

Inspect object-storage paths, signed links, cache keys, search indexes, and queued jobs for tenant context. An export worker needs to know which user and organization authorized the task, not just the job identifier. Cached results also need an isolation rule appropriate to the data they contain.

Review support and administrative workflows explicitly. Legitimate cross-tenant access should have a defined purpose, narrow permissions, and an audit trail. Treat backup restores and data offboarding as ownership-sensitive operations too; they can move records through paths ordinary customer actions do not use.

References: [1] OWASP, [4] OWASP

Verify the boundary after change

Retest using both organizations and relevant role transitions. Confirm that authorized access succeeds and cross-tenant access is denied without disclosing sensitive record details. Repeat the checks through synchronous requests, asynchronous results, and downloadable artifacts where those paths are in scope.

Add regression coverage close to the policy decision and preserve an integration-level ownership test. If a shared authorization helper changes, review consumers that may set or interpret tenant context differently. Track accepted cross-tenant operations separately so broad administrator privileges do not become the accidental default.

References: [1] OWASP, [5] OWASP

Your next steps

1. Document shared and tenant-owned resources with expected permissions.
2. Create separate synthetic organizations and role-transition scenarios.
3. Trace ownership through APIs, storage, caches, queues, and support tools.
4. Book a review of the highest-impact tenant boundaries before a sensitive release.