Security teams should test authorisation by replaying the same API call with different identities, roles, and token scopes to confirm each one receives only its allowed objects and actions. That includes checking direct object references, forced browsing, and privilege boundaries with user, admin, service account, and delegated tokens.
Testing authorisation across identities without false confidence
Authorisation testing should treat the same request as a control surface, then vary the caller identity and the token context around it. The point is to prove that access changes only when the policy says it should, and that object-level and function-level boundaries still hold when the caller switches from a standard user to an admin, a service account, or a delegated token.
The most useful tests are comparative, not absolute. If one identity can read, update, or enumerate an object while another cannot, the team needs to confirm that the difference comes from an intended entitlement or scope, not from a hidden path such as an IDOR, forced browsing, inherited role, or overly broad token.
What to vary in the test matrix
Build the matrix around the identities that actually exist in production, then exercise them against the same object and action set. For example, replay the same API call with a low-privilege user, a privileged operator, a service account, and any delegated or application token that can reach the same endpoint. The response should change in a predictable way for each identity, while the request format stays constant.
Scope matters as much as role. A token with read-only scope should not gain write behaviour just because the caller has a broader role elsewhere, and a delegated token should not inherit permissions that the originating user did not explicitly grant. This is why teams should test object visibility, action permission, and scope enforcement together rather than as separate checks.
- Test the same object ID with different callers to catch broken object-level authorisation.
- Test the same action with different scopes to catch privilege leakage across token types.
- Test cross-tenant, cross-role, and cross-environment access where those boundaries exist.
- Check both success paths and denied paths, because missing denies often reveal the real bug.
How to recognise a failure that matters
A meaningful failure is not just an unexpected 200 response. It is any case where the caller can see, change, or infer more than its identity should allow, especially when the access path is indirect. Forced browsing, predictable object references, and overly reusable credentials often surface only when the same test is replayed from multiple identities and the team compares the deltas carefully.
It is also worth looking for identity confusion between humans and non-human callers. If a service account can perform an action that a human admin can perform only with a step-up or approval, the policy may be too loose. If a delegated token can access objects outside the delegated user’s footprint, the application may be enforcing privilege at the wrong layer.
Risk and Threat Considerations
Authorisation flaws are dangerous because they usually fail quietly. An attacker, or even a legitimate user with an overbroad token, can move from one allowed object to many disallowed objects by changing only the identifier, the scope, or the calling principal.
Failure mechanism: The application validates the request shape but not the caller-object relationship, so different identities receive inconsistent access decisions for the same operation.
Impact: That creates data exposure, unauthorised action, and lateral movement across roles, tenants, or service boundaries, especially when object references are guessable or tokens are overprivileged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Tests object access across identities and catches IDOR-style exposure. |
| Recommendation — Replay object requests with multiple identities and verify each only reaches authorised objects. | ||
| OWASP ASVS | V8 — Authorization | Directly supports verification of role, scope and object-level access decisions. |
| Recommendation — Validate that each role and token scope is enforced consistently on every protected action. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Authorization testing should confirm identities receive only the access they need. |
| IA-5 — Authenticator Management | Token and credential scope are central to testing how identities are authorised. | |
| Recommendation — Review results for excess privilege and remove permissions that are not required. Check that token and credential handling preserves the intended access boundaries. | ||
| MITRE ATT&CK | T1069 — Permission Groups Discovery | Comparing identities exposes excessive permissions and unexpected access paths. |
| Recommendation — Hunt for overbroad group membership and entitlement sprawl when tests reveal unexpected access. | ||
Practitioner Guidance
What to prioritise: Start with the highest-risk paths first, meaning read/write endpoints, privileged workflows, and any API that touches shared or sensitive objects. Those are the places where a single missed check usually has the biggest blast radius.
What to verify: Confirm that the policy decision changes for the right reason, not because the test harness changed headers or reused a cached session. The strongest result is a repeatable deny for disallowed identities and a narrowly bounded allow for permitted ones.
Common mistake: Teams often test only one “good” user and one “bad” user, then assume the whole matrix is covered. That misses the real failures, which usually appear when a service account, admin token, or delegated credential behaves differently from the humans already tested.
Practitioner takeaway: Authorisation testing is only trustworthy when it proves that the same request is constrained correctly across every identity that can reach it, not just across the obvious user roles.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org