API Authorization Review

Summary

API authorization determines whether an authenticated principal may perform a specific action on a specific resource in a specific tenant or business context. Authentication success does not prove authorization. Possession of a valid token does not prove permission for every object, field, operation, export, or asynchronous job.

Why it matters

API clients can be web applications, mobile apps, services, partners, jobs, or internal tools. UI restrictions are not security controls, and hiding an object identifier does not enforce authorization. Read and write authorization can differ. Bulk and export functions can bypass ordinary object checks unless they are designed and tested explicitly.

When to use this guidance

Use it during API design, change review, security assessment, incident follow-up, access-control defect review, or before enabling a new role, tenant, partner, or automation. Test only approved environments and accounts. Do not use real credentials, customer data, or production actions outside authorized procedures.

Prerequisites

Define users, roles, tenants, services, trust boundaries, sensitive resources, expected business rules, test identities, and evidence handling. Inventory REST, GraphQL, RPC, mobile, partner, internal, webhook, bulk, and asynchronous operations.

Authentication and authorization

Authentication establishes an identity claim. Authorization evaluates permission. Separate valid token, sufficient scope, valid role, object ownership, tenant membership, function permission, field visibility, resource existence, business-rule authorization, and administrative override. A 404 may intentionally conceal existence, but backend authorization must still occur.

Object and tenant boundaries

For every object operation, establish owner, organization or tenant, parent resource, lifecycle state, and required relationship. Object-level authorization prevents one user from reading or changing another user's record. Function-level authorization restricts privileged operations. Tenant isolation applies even where identifiers are predictable or a support role can search across approved scope.

Roles, scopes, and ownership

Roles, scopes, and claims can express coarse authority; ownership and business rules often provide the final decision. Service-to-service identities need least privilege and documented scope. Administrator access needs explicit boundaries and audit evidence. Client-side checks and API gateway policy can help, but a gateway may not understand backend business rules.

Enforcement points

Map each operation to gateway controls, backend authorization, database filtering, policy-as-code where used, and logging. Default-deny behavior is safer than assuming a route is private. Data filtering, field selection, batch operations, exports, webhooks, and job status endpoints require the same review as primary CRUD operations.

Practical review workflow

Define principals, roles, tenants, services, and trust boundaries.
Map each operation to resource, ownership, tenant, and function decisions.
Review token claims, gateway and backend enforcement.
Test positive and negative cases, including cross-user and cross-tenant access.
Review administrators, service identities, bulk, export, webhook, and asynchronous operations.
Remediate at the authoritative enforcement point, retest, document evidence, and reassess after role, API, or data-model changes.

Negative testing

Case	Expected behavior	Common failure
Valid owner	Permitted action	Missing business rule
Valid non-owner or cross-tenant	Denied or bounded response	Identifier-only lookup
Insufficient scope or role	Denied	Role assumed by UI
Service account or administrator	Approved scoped path	Unbounded privilege
Bulk export, hidden field, webhook, job	Bounded data and operation	Secondary path bypass

Evidence to collect

Collect operation inventory, required authorization decision, policy or code reference, test principal and tenant, expected and actual result, logs, data scope, exception approval, remediation, and retest evidence. Do not preserve tokens or sensitive payloads in general-purpose notes.

Common mistakes

Do not equate authentication with authorization, rely on hidden identifiers, trust client controls, assume role checks cover ownership, assume a gateway protects backend rules, ignore field-level output, or omit export and asynchronous paths.

Worked example

A fictional multi-tenant business API lets a standard user read owned records, a support role assist within approved tenant scope, and an administrator manage selected functions. A valid token and object identifier unexpectedly return cross-tenant data through a bulk export endpoint because only gateway checks run there. Backend ownership enforcement is added, export filtering is retested with non-owner and cross-tenant cases, and logs are reviewed. The conclusion is an authorization flaw corrected and retested; no claim is made about historic data access without evidence.

Remediation and validation

Fix the authoritative backend or policy layer, then test owner, non-owner, tenant, role, scope, service, administrator, bulk, field, webhook, and job cases as relevant. Confirm errors and audit logs do not expose more than intended. Document residual risk and owner.

Logging and monitoring

Log authorization decision context, principal type, operation, tenant or resource scope, outcome, and correlation data under local privacy policy. Logging is not a substitute for enforcement, and absent logs do not prove a request did not occur.

Reassessment triggers

Reassess after new roles, scopes, APIs, data models, tenant features, gateway changes, partner integrations, jobs, or authorization incidents.

Limitations

Authorization behavior depends on implementation, provider, framework, and business rules. This guidance is not an exploit guide and does not prove complete coverage or historical access.