Build an API inventory for an authorization review
Inventory API operations, roles, ownership rules, and background effects. Find gaps between your schema and the routes that actually run.
For an API authorization review, list operations rather than URLs alone. Reading an invoice, updating it, exporting a collection, and downloading the resulting file can use different permission checks. A route inventory should show the actor, object owner, action, and downstream effect for each operation.
An OpenAPI document is a useful starting point, but it is not proof that the running service matches the document. Compare it with the deployed route configuration and the owner-approved workflows. Do not discover extra systems by scanning outside the agreed scope.
What fields make the inventory useful?
| Field | Fictional example |
|---|---|
| Operation | Export invoices |
| Entry point | Approved API export route |
| Actor | Workspace member |
| Object boundary | Current workspace's invoices |
| Policy | Export permission and active membership |
| Processing | Queue worker creates a file |
| Result access | Authorized download endpoint |
| Evidence owner | Billing application team |
Use placeholders in public examples. Exact routes, tenant identifiers, and infrastructure details belong in the private review record.
Where do inventories miss authorization paths?
Check documented alternate methods and route versions. A retired-looking mobile endpoint may still be deployed. An administrator route may share a handler with a public route. Bulk operations may accept object identifiers individually and require checks for every item.
Include asynchronous results. Authorization at job creation does not by itself establish authorization at result download, especially after a membership change. Record whether the job runs with the user's identity, a service identity, or a captured permission state.
Separate object-level and function-level access. OWASP's API authorization guidance explains why an authenticated caller still needs permission for the particular object. An inventory should make those decisions visible rather than reducing every route to “requires login.”
How do you use the inventory to choose tests?
Attach the test account matrix and expected allow/deny cases. Prioritize operations that cross a boundary or create durable effects: exports, invitations, role changes, file access, and integrations.
Mark each row as reviewed, tested, blocked, or out of scope. Keep the deployed build identifier beside the inventory version. If a route changes during the review, record whether the result still applies.
This gives engineering a usable handoff: a list of behaviors and evidence, not a vague claim that the API was checked. Ask Sourced about a scoped API review when you need help turning the inventory into a focused assessment.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.