API Authorization Fails Quietly: Test Every Object, Role, and Action

In brief: Authentication proves who made a request; authorization decides what that identity may do. API security breaks when teams test the first question and assume the second one works everywhere.

A valid token is not a permission slip

Modern APIs often put strong authentication in front of weak object-level controls. A request can carry a perfectly valid session or access token and still ask for another customer's invoice, project, export, or administrative action. If the handler checks only that the caller is logged in, the API has answered the wrong security question.

This failure is easy to miss because normal product testing follows the intended path. The owner opens the owner's record, an administrator uses an administrator endpoint, and every request succeeds exactly as expected. Authorization defects appear only when the identity, object, tenant, or action is deliberately mismatched.

Build a complete authorization matrix

• Test every object operation as the owner, a peer in the same tenant, a user in another tenant, and an unauthenticated caller.
• Exercise read, create, update, delete, export, invite, and approval actions independently; one protected method does not prove the others are protected.
• Change identifiers in paths, query parameters, JSON bodies, headers, and nested objects instead of testing only the obvious URL field.
• Verify role transitions and stale sessions so demoted or removed users cannot retain privileges through cached claims.

Deny by default at the data boundary

The most reliable design binds every query to both the requested object and the caller's authorized scope. Fetching a record by identifier and checking ownership later creates room for forgotten checks, side channels, and inconsistent error handling. Querying within the tenant or ownership boundary makes the safe condition part of retrieval itself.

Central policy helpers reduce drift, but they are not a substitute for tests. Each endpoint still needs negative assertions proving that forbidden identities receive no data and cause no state change. A 403 response is useful evidence only when the database and downstream side effects remain untouched.

Evidence should prove the forbidden path stayed closed

A useful authorization test captures the caller, role, tenant, target object, request, response, and post-request state. That evidence distinguishes a real control from a front-end restriction or a status code masking an action that already happened.

KENSAI treats access-control validation as a matrix rather than a single happy-path scan. The goal is to prove isolation across identities and actions, then preserve enough evidence to reproduce any boundary failure and verify its remediation.

Takeaway

Authorization is a relationship between an identity, an object, and an action. Test all three dimensions with negative cases, and prove that forbidden requests produce neither data exposure nor side effects.