Why authorization testing needs business context
Access-control flaws often look legitimate at the HTTP layer. Finding them requires understanding who owns each object, which actions each role should perform and where a workflow changes trust boundaries.
Published · 6 minute read
Why scanners miss authorization failures
A scanner can identify endpoints and compare status codes, but it rarely understands whether invoice 481 belongs to the signed-in customer, whether a support agent should see its payment history or whether an approver may edit a request after approval.
The request can be syntactically valid and return an ordinary 200 response while still exposing another tenant's data or allowing an action outside the user's authority. The defect is in the business rule, not the HTTP grammar.
What a useful authorization model includes
Testing starts by mapping actors, resources and permitted actions. Ownership, tenant boundaries, lifecycle states and delegated access matter as much as named roles.
- Horizontal access: one user attempting to read or change another user's objects
- Vertical access: lower-privileged roles reaching administrative actions
- State transitions: actions that become invalid after approval, cancellation or closure
- Indirect paths: exports, search, notifications and APIs exposing the same protected data
Evidence developers can act on
A strong finding identifies both the affected endpoint and the missing rule. It documents the expected authorization decision, the role and object used in the test, a minimal reproduction and the related paths that need the same control.
Retesting should verify the shared authorization policy rather than one patched identifier. Otherwise the original endpoint may be fixed while exports, bulk actions or a mobile API remain exposed.
Need this tested in your environment? Talk to a Trinetrix specialist.