Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A user can sign in correctly and still receive another organisation’s document through an API. Testing tenant boundaries requires explicit expectations about identity, object and action, not simply evidence that the endpoint demands a valid session.
Consider a fictional document portal with two synthetic organisations, Cedar and Harbour. Each has an ordinary reader and an administrator, and each owns test documents with distinct markers. The team will exercise only these approved fixtures in an isolated environment, turning the access model into repeatable regression tests.
API authorisation needs an explicit decision model
Describe the requesting identity, its tenant membership, the target object’s ownership and the requested action. Add contextual rules that genuinely affect the decision, such as document state or a delegated sharing grant. If the product allows cross-organisation collaboration, represent that permission explicitly instead of assuming every cross-tenant request must fail.
For the document portal, ordinary readers may view published documents belonging to their organisation. Administrators may manage documents within their own organisation, while a separately approved sharing workflow grants narrower access to selected external readers. This example policy is a design exercise, not a claim about a particular production application.
Review the model with the product and application owners before implementing tests. A test can faithfully enforce the wrong assumption. The written decision table becomes the reference when developers disagree about whether a result is a defect or an intended collaboration feature.
Build fixtures that make a boundary failure obvious
Create synthetic identities and documents with stable ownership relationships. Give each document a harmless marker so a test can detect an unexpected body without relying on real data. Ensure the fixtures are created through the application’s supported setup path, including any required membership records.
Avoid sharing one powerful account across the entire suite. It can conceal the difference between a reader’s permissions and an administrator’s permissions, or make every test pass because the fixture bypasses ordinary enforcement. Store credentials through the runner’s approved secret mechanism and keep tokens out of test output.
Establish that each identity can complete one expected allowed operation before evaluating its denied operations. If Harbour’s reader cannot authenticate at all, a denied Cedar document request does not prove that the tenant check worked. It may simply show that the test never reached authorisation.
API authorisation tests should vary one dimension
Start from a valid request and change one relevant dimension at a time. This makes failures easier to explain and reduces the chance that several invalid fields mask the missing boundary. Keep method, route shape and fixture state stable while changing the target object’s ownership.
| Identity and action | Target | Expected outcome |
|---|---|---|
| Cedar reader views | Published Cedar document | Allowed |
| Cedar reader views | Unshared Harbour document | Denied |
| Cedar reader modifies | Cedar document | Denied |
| Cedar administrator modifies | Cedar document | Allowed |
| Cedar administrator modifies | Harbour document | Denied |
| Explicit external recipient views | Specifically shared document | Allowed within grant scope |
The exact denial status should follow the application’s documented contract. More importantly, verify that the response contains no protected document content and that a denied mutation did not alter state. An error status alone can miss a handler that performs the write before returning the denial.
Apply the model to lists, exports and nested resources
Object-detail routes are only one part of the surface. A list can reveal another tenant’s metadata, an export can include unfiltered records, and a nested route can trust a parent identifier without checking the child’s ownership. Inventory those operations before declaring the boundary covered.
For the portal, compare the reader’s list, search and export results with the same approved fixture set. Verify counts and identifiers as well as document bodies. If a response includes pagination or a continuation token, exercise the next page instead of checking only the initial result.
Test contradictory parent and child references with controlled fixtures. A request naming Cedar in the route but Harbour’s document identifier should not become authorised merely because one identifier passed validation. The server must make a coherent decision about the actual object and operation.
Keep enforcement on the server side
Hiding a button in the interface does not prevent a caller from sending the API request. The server must validate the relevant permission whenever the operation is requested. Central enforcement can reduce omissions, but its configuration and the object lookup path still need review.
OWASP recommends denying access by default and checking permissions on every request. In the portal exercise, inspect whether the handler loads a document through a tenant-scoped query or checks ownership after retrieval, and whether all return paths preserve the rule. Do not infer that a shared middleware name proves that every object-level condition is enforced.
Avoid trusting a tenant identifier supplied by the client as the sole authority for access. Resolve the requester’s permitted context through the application’s authenticated identity and membership model. If users can select an active organisation, test that switching context still requires valid membership.
Exercise changes to grants and object state
Permissions change while sessions remain active. Remove the synthetic sharing grant and verify the recipient loses the intended access according to the application’s documented propagation behaviour. Treat cache invalidation and session lifetime as explicit test conditions rather than silently allowing yesterday’s grant forever.
Also move a document between supported states, such as draft and published, and rerun the affected operations. A reader permitted to view a published record may not be permitted to view its draft replacement. State transitions can expose missing checks even when tenant identifiers never change.
Keep these tests deterministic by controlling the fixtures and recording expected convergence. If a distributed permission system is involved, distinguish an allowed propagation interval from an unbounded stale decision. Report the actual observation rather than labelling every transient response a confirmed isolation failure.
Retain a coverage record alongside the results
Map each test to a route, role, object relationship and action. Record intentional exclusions and unsupported operations so the suite’s limits remain visible. A green result means the defined matrix passed for that revision and environment; it is not proof that every endpoint enforces the same policy.
When a defect is found, retain a minimal failing fixture and add the relevant regression before closing it. Link the correction to the tested application revision. The next developer should be able to reproduce the boundary check without access to customer accounts or a recording of the original investigation.
Key takeaways
- Define access using identity, tenant membership, object ownership and action.
- Pair denied tests with allowed controls and verify that denied mutations leave state unchanged.
- Cover lists, exports, nested objects and permission changes as well as detail routes.
- Keep the tested matrix and its exclusions visible beside the passing result.
How SecurityVault approaches this
SecurityVault’s API security workflow connects API inventory and analysis with application context. That helps teams identify the interface and owner associated with a concern, including differences between documented and implemented routes. An inventory gives the test plan a starting surface; it does not independently prove tenant isolation.
The DAST workflow contributes evidence from a running application within its configured scope. Authentication setup and route coverage must be verified before interpreting the result. Object-level authorisation also needs the explicit identities, fixtures and business expectations described in this guide; a general scan cannot be assumed to invent the correct access model.
During an evaluation, use synthetic organisations and a small approved route matrix to examine how findings and supporting evidence reach the responsible engineer. Confirm what was tested and keep untested operations visible. To discuss a scoped exercise for your application’s permission model, request a demonstration.