Access control testing: can one tenant read another’s data?

What to test

• Role-based access: each role can do what it’s meant to, and is refused the rest (an employee can’t create a company).
• Tenant isolation: in a multi-tenant product, a user of one customer never sees, changes or deletes another customer’s records, also not by guessing an id.
• IDOR (insecure direct object references): an endpoint that takes an id checks that the caller may use that id, not just that the caller is signed in.
• Writes into another tenant: creating, moving or assigning a record with a reference that points at another customer is refused.
• Unauthenticated access: every endpoint that should need a sign-in answers 401 without one.

How to test it

1. Make test accounts for every role, in at least two tenants, each with a few records of its own.

2. For every endpoint, call it as each role with its own ids: this should work where the role may do it.

3. Call it again with ids that only another tenant can see: this should be refused with 403 or 404.

4. For list endpoints, check the answer only contains the caller’s tenant.

5. Call every endpoint without a token: it should answer 401, unless it’s meant to be public.

6. Decide, per finding, whether it’s intended, and keep those decisions as the expected policy.

Common pitfalls

• Testing only with the admin role, which may do everything and so never shows a missing check.
• One tenant in the test data, so isolation can’t be tested at all.
• Checking only that the screen hides a button; the API behind it is what decides.
• Testing it once before a release; access rules change with every new endpoint and role.

Access control testing in Journey Lanes

Flows in Journey Lanes can contain refusals as steps: a step with a status check of 400 or more passes when the API refuses, so “a company admin can’t delete a company” is a step like any other.

The access audit goes further: every role from your flows signs in and probes every endpoint, with its own ids, with ids only other roles can see, with writes that point at another tenant, with list endpoints, and without a token. Findings are ranked from critical (cross-tenant access) to blocked steps, and your decisions become the access policy the mock backend enforces (access audit).