# API authorization: test the actor, object and action together Canonical: https://www.web3sec.news/blog/api-authorization-review-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: APIs & authorization Published: 2026-11-08 Updated: 2026-11-08 A practical review method for cross-tenant access, administrative functions, exports, background jobs and failure behavior. ### Diagram: Authorization belongs at the resource boundary. Authenticate the caller, then evaluate what this caller may do to this resource. ![An authenticated principal requests an object and action. The server checks object ownership or tenant, permitted action, and current business state before accessing the scoped resource. A client-supplied identifier is input, not permission.](https://www.web3sec.news/diagrams/api-authorization-boundary.svg) [Full-size SVG](https://www.web3sec.news/diagrams/api-authorization-boundary.svg) · [PNG download](https://www.web3sec.news/diagrams/api-authorization-boundary.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Build an access model from real operations Assign an application owner and map actors to operations and objects. Include anonymous visitors, ordinary users, tenant administrators, support operators, service identities and background workers. List read, create, update, delete, export and privileged-state transitions separately. A role name alone rarely captures ownership, tenant membership, resource state or whether the user should perform a particular action right now. Inventory routes beyond the visible interface: mobile APIs, GraphQL resolvers, old versioned endpoints, signed downloads, batch operations, webhooks and internal administration. Record where identity is authenticated and where the authorization decision occurs. OWASP recommends checking permissions for every request and denying access by default. A hidden button or unguessable identifier is not evidence that the server enforces that policy. ## Apply decisions where the protected data is used Load the resource within an authorized scope, or evaluate the actor’s relationship to the specific object before returning or changing it. Derive tenant context from verified server-side state rather than trusting a submitted tenant identifier. Validate fields and business transitions as well as route access, so a legitimate update cannot silently promote the caller or reassign another customer’s object. Treat token validation, browser-origin policy and authorization as separate concerns. The REST Security guidance covers token and transport considerations; none makes an authenticated request automatically entitled to its target object. Apply the same rules to asynchronous work, where a job may execute after membership or permissions change. Decide explicitly whether authority is rechecked at execution and what happens when it has expired. ## Create a meaningful negative test matrix Create synthetic users in two test tenants and an administrator with a limited support role. Exercise each important operation as the owner, another user in the same tenant, a user in the other tenant and an unauthenticated caller. Change object identifiers, nested parent identifiers, batch members and requested fields. Verify the side effect and stored state, not merely an HTTP status or response message. Test failure paths: unavailable policy service, malformed token, revoked membership, expired link and missing ownership record. They should not broaden access. Include concurrency for important business transitions such as approvals or transfers. Keep a small number of durable integration tests around the actual authorization boundary rather than duplicating UI checks that can pass while the server remains exposed. ## Detect misuse and close the response loop Log enough context to investigate denied and sensitive successful operations: actor, tenant, action, resource identifier, decision and correlation ID. Avoid recording bearer tokens or full sensitive response bodies. Alert on meaningful patterns such as repeated cross-tenant attempts followed by an export, with thresholds appropriate to legitimate client behavior. Route the alert to someone who can suspend the affected identity or feature. For a confirmed authorization defect, contain the affected path, identify reachable historical data and preserve evidence of access. Repair the policy at its shared enforcement point and add regression coverage for the discovered class. Review related endpoints and background jobs for the same assumption. Completion means the prohibited operation no longer succeeds and the team understands the likely exposure, rather than only closing the original report. ## Controls to take away - Authentication establishes identity; authorization governs the exact operation. - Test stored state and side effects alongside responses. - Review asynchronous work after the caller’s authority changes. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Map actor, object, action, tenant and state. - [ ] Inventory legacy, batch, export and asynchronous paths. - [ ] Enforce policy on the server at every protected operation. - [ ] Test synthetic users across two tenants. - [ ] Verify side effects and deny-safe failure behavior. ## Sources & further reading - [OWASP: authorization cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [OWASP: REST security cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)