Multi-tenant products share infrastructure while promising customers separate data and authority. That promise needs to survive every way a record can be read, changed, or exported. A polished user interface is only one view of the underlying access controls.
Create a permission matrix
Start with two controlled tenants and a small set of records belonging to each. Give the records clear labels so that a response can be attributed to the right owner. Add multiple roles within each tenant.
For each object type, list the operations that matter: view, create, update, delete, export, and share. Record the expected result for each user. This matrix lets testers distinguish a role failure from a cross-tenant failure and gives developers a useful regression plan.
Follow the object across access paths
An object may appear in a detail endpoint, a search response, a bulk export, and an asynchronous job. Check whether each path makes its own authorization decision. A control in one request handler does not automatically protect another.
OWASP’s guidance on insecure direct object references describes testing whether a user can access an object without the appropriate permission. For SaaS products, the relevant permission often includes both tenant membership and the allowed action.
- Detail, list, search, and bulk-operation endpoints.
- Download links, generated exports, and background job results.
- Invitations, shared links, and support or administrative tools.
- Webhooks, integrations, and older API versions that remain accessible.
Check changes in access over time
Permissions are not static. A user can leave a team, change roles, or lose access to a shared record. Test what happens to existing sessions, API credentials, cached responses, and already generated links after that change.
Write down the intended revocation behavior before the test. Some products deliberately issue expiring links; others promise immediate revocation. The assessment should compare the implementation with that stated boundary rather than assume every product has the same design.
Make the evidence safe and actionable
Use only the accounts and records authorized for the engagement. To demonstrate a failure, collect the minimum evidence needed to show the wrong user obtained access. Synthetic records make this much easier.
Document the starting identity, expected ownership, affected operation, actual result, and cleanup. Remediation should address the shared authorization rule and all relevant access paths. Retest with the original scenario and with neighboring roles and object types, so a local fix does not leave the same design error elsewhere.
Test tenant isolation as a matrix of users, objects, operations, and access paths. A single denied request does not establish the whole boundary.