Authentication is only the starting point
A valid login establishes who is calling an API. It does not establish that the caller may read a particular record, change a sensitive field or perform an administrative operation. Many application defects live in the space between these decisions. A request can be perfectly authenticated and still cross an access boundary.
OWASP identifies broken object-level authorization as a major API risk. A practical review asks what the server knows about the caller, the requested object and the action at the moment access is granted. Do not rely on a hidden button, an unpredictable identifier or a check in the browser as the permission decision. Those mechanisms do not replace server-side authorization.
Build a permission matrix small enough to use
Choose a representative workflow and list its actors, objects and actions. For an example document service, actors might be a document owner, another member of the same organisation, a member of another organisation and a support operator. Actions might include viewing, editing, exporting, deleting and changing sharing settings.
Write the expected result for each meaningful combination. Include the reason: ownership, an explicit share, a role or a specific operational permission. Ambiguous cells are a design issue to resolve before testing. Start with a compact matrix that developers and the product owner can actually review, then expand to the highest-impact workflows.
Exercise object and tenant boundaries safely
In an authorised test environment, create two synthetic tenants and several users with different roles. Capture legitimate requests made by each user, then use the test accounts to check whether a caller can address an object belonging to the other tenant. Test both direct object endpoints and the search or list endpoints that reveal objects indirectly.
Check nested resources as well. A server might validate access to a project but fail to verify that an attachment really belongs to that project. Bulk endpoints deserve attention because one accepted item can hide an incorrectly authorised item in the same request. Use synthetic records and a controlled environment; never probe other customers’ data to validate a hypothesis.
Review the fields and actions inside the boundary
Object access is not the end of the review. A user allowed to update their profile should not automatically be allowed to change their role, organisation identifier or approval status. Define the accepted fields for each operation and check sensitive transitions explicitly. Also review what the response exposes, including internal notes and integration identifiers.
Try permitted and forbidden transitions separately. For example, a user might be allowed to save a draft but not publish it, or view a report but not export its underlying records. Confirm that the API enforces those differences even if the normal interface never offers the forbidden action. Record expected denials alongside expected successes so fixes do not accidentally break legitimate use.
Follow authorization into asynchronous work
Exports, scheduled reports and background jobs often execute after the original request has finished. Decide which identity and permissions apply when the work runs and when its output is retrieved. A job created by an authorised user should not automatically make its result available to anyone who can guess or obtain the output URL.
Consider what happens when membership changes between scheduling and execution. The correct behaviour depends on the product, but it should be deliberate. Test revoked access, a deleted tenant and a report shared with a narrower group than its source data. Include caches and signed download links in the review because they may preserve access after the primary record changes.
Make the evidence useful to developers
A helpful finding states the intended rule, the smallest reproducible request sequence, the observed result and the affected boundary. Provide synthetic identifiers and avoid copying real personal data into a ticket. Distinguish a demonstrated cross-tenant access failure from a suspicious design that still needs investigation.
After remediation, add a focused regression test at the layer where authorization is enforced and verify the affected workflow end to end. Prefer consistent policy enforcement over scattered ad hoc checks. Keep the permission matrix close to the feature’s documentation so a future change to sharing, roles or tenancy triggers a review. Authorization is a continuing product contract, not a one-time scanner result.