Testing API Authorization with a Two-Account Access Matrix

Use synthetic users and an explicit access matrix to uncover object, function, and tenant authorization failures in APIs.

An API can correctly identify a user and still return a record that belongs to somebody else. Authentication establishes who is calling; authorization decides whether that caller may perform this action on this object. A useful API pentest makes those decisions visible.

Model the expected decisions

Imagine a project management service with two organizations. Create synthetic users Alice and Ben in different organizations, plus a manager in Alice's organization. Give each account its own project and invoice.

Build a compact matrix before testing:

Action	Owner	Same-organization manager	Other-organization user
Read an invoice	Allow	Allow if policy permits	Deny
Edit project settings	Allow if role permits	Allow if policy permits	Deny
Export organization data	Role-dependent	Role-dependent	Deny

Have the product owner confirm the intended policy. A tester cannot reliably identify an authorization defect without knowing what access is intended.

Compare controlled requests

Using only approved test objects, replay a successful read request with the other synthetic user's credentials. Keep the object reference unchanged. The server should deny access and return no protected fields. An error status is insufficient if the response body still contains the invoice.

Repeat the comparison for updates, deletion, exports, and background job results when those actions are in scope. An application may protect its detail endpoint while overlooking a bulk operation. Avoid touching real customer objects to establish the same point.

Look beyond object identifiers

Review whether the server derives organization membership and privileges from trusted session information. Client-supplied tenant IDs, role fields, and ownership fields require independent checks. Random identifiers make guessing harder, but they cannot replace authorization.

For each finding, record the two account roles, synthetic object, expected decision, actual response, and minimum reproduction steps. Explain whether the problem crosses an ownership boundary, a role boundary, or a tenant boundary.

Keep the fix testable

Apply policy checks consistently in the service layer or shared authorization mechanism used by every relevant route. Add regression cases for both permitted and forbidden actions. Retesting should cover nearby endpoints that rely on the same decision.

See OWASP's authorization testing guidance and Authorization Cheat Sheet for further guidance.