Cybersecurity
API authorization: check owner, action and every access path
By the BackendDrills editorial team · Published and checked October 6, 2026 · 6-minute read
Before you start: Authenticated requests and resource ownership. Find this reading in a study path →
A valid login establishes an identity under the authentication contract. Authorization decides whether that identity may perform this action on this resource. Enforce that decision on the server, including access paths that bypass the visible user interface.
An original two-user fixture
Create synthetic accounts Amber and Blue, each owning one report. Amber can load her report through the normal screen. Now ask whether she can change the URL to Blue's report ID, request its export endpoint, update a child object or retrieve an older cached response. A hidden button is not an authorization boundary, and an unpredictable ID does not replace a permission check.
| Caller and action | Expected result |
|---|---|
| Amber reads Amber's report | Allowed under the read policy. |
| Amber reads Blue's report | Denied without disclosure of report contents. |
| Amber edits a read-only shared report | Denied under the action-specific policy. |
| Background job exports a revoked report | Decision follows the documented permission lifecycle. |
Trace the same decision across routes
Derive caller identity from the verified session or token, then evaluate ownership and action against trusted resource state. Do not accept an ownerId in a request body as authority merely because it is well formed. List endpoints, direct object reads, mutations, exports, caches and asynchronous jobs need explicit handling consistent with the policy.
A cache key and cache-hit path must respect the intended permission scope. If authorization can change, decide how an old cached response becomes unusable. A role name alone may be insufficient when the rule depends on tenant, object ownership or resource state. Document revocation expectations instead of silently assuming permissions are permanent.
Practice a negative-test review
- List resources, callers and actions before selecting test cases.
- Use at least two owners, a read-only relationship and a revoked relationship.
- Exercise the direct API as well as the normal screen.
- Repeat after warming the cache with an allowed request.
- Check stored changes and response contents, not only HTTP status.
Keep denial behavior and logs deliberate: the response should not disclose private data, while audit records should support investigation without storing secrets. Finish with a permission matrix and one test that would fail if a developer accidentally skipped the ownership check. Apply the same boundary to AI tool calls: generated arguments are input to validate, not permission to act.
Check the underlying behavior
Original illustrative examples, prepared with AI assistance and checked against the linked primary documentation. No customer incident or vendor endorsement is claimed. Our editorial approach.
Practice the next decision
Try a complete free backend drill: inspect evidence, make three decisions and review the reasoning. No account or card required.
Try a free incident drill →Selected practice from the study paths
- A cache hit returns another tenant’s data. · Full edition drill
- Changing a resource ID exposes another user's record · Full edition drill
Free readings need no account. Full edition drills require verified access; opening a paid link does not expose its answers.