Tenant isolation: proving the API makes the right decision

Hold one variable constant

Start with a valid request for tenant A. Repeat the operation with a principal from tenant B while keeping the object constant, then test a different object with the original principal. These controlled comparisons help distinguish an authorisation failure from a malformed request or missing prerequisite.

Check each operation independently

Read, update, approve, export and delete can have different enforcement points. The fact that a list endpoint filters objects correctly says little about a direct object endpoint or an export download. Use the documented role matrix to decide what should be accepted and what should be denied.

Look beyond the response status

Check object ownership, persisted state and the audit principal. Some services return a generic success response before a background worker performs the action. Follow the approved job to its result and confirm which tenant’s data or authority it used.

Retest the policy boundary

A durable fix binds the authenticated principal to the relevant tenant, object and operation on the server. Test legitimate delegation as well as denial. Random identifiers and hidden controls can reduce accidental discovery but cannot replace that business authorisation decision.

Use a deliberate comparison set

Create two customer organisations with separate synthetic resources and test identities. First confirm that each can perform its legitimate operations. Then repeat an agreed operation against the other organisation's canary object, holding the rest of the request stable. This makes the result easier to interpret than random identifier substitution. Include the product's genuine cross-organisation roles separately; a support or platform operator may have a different policy from an ordinary customer user.

Test distinct operation classes where they exist: retrieval, modification, export, search and administrative actions. Success on one read comparison does not establish that every route handling the same object uses the same policy decision.

Look for context changes inside the workflow

Ownership context may pass from the web service to a queue, worker, cache or file store. Identify those handoffs within the scope and decide where the expected decision must remain bound to the requesting organisation. A correctly rejected front-end call is useful evidence, but an asynchronous export or independently accessible result link may need a separate check. Use synthetic data and a small, owner-approved set of operations.

The patient portal authorisation guide explores comparable relationship changes, including delegated access and revocation. The business rules differ, but both settings benefit from testing the lifecycle of a permission rather than only its initial creation.

Retest the policy and the permitted workflow

Write the acceptance condition in terms of principal, operation and ownership. Record the denied response and any relevant downstream state, with a correlation reference where available. After remediation, verify that the legitimate customer can still perform the intended action and that the agreed adjacent interface applies the same policy. If the implementation centralises authorisation, validate the observed result rather than assuming the architectural change is sufficient.

Where an action moves value or changes transaction state, use the additional comparisons in our payment authorisation pentest guide. Tenant ownership and maker-checker separation are complementary controls; a finding should identify which decision failed instead of using “access control” as an unexplained catch-all.

Put the guidance to work

Use the readiness checklist to document assumptions, or inspect the fictional Fintech AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.