Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement. That failure usually appears as BOLA, broken function-level access, or mass assignment. Security teams should test whether an authenticated caller can move from one object, record, or action to another without additional approval.
Why This Matters for Security Teams
Strong authentication only proves that a caller is known, not that the caller should be able to perform the requested action. When authorisation is weak, a valid session can become a direct path to overexposure of records, functions, and administrative actions. That is why broken object-level access and broken function-level access keep appearing in incident reports even when login controls look sound.
The practical risk is larger than data theft. Weak authorisation can let an authenticated user change approvals, alter identities, delete logs, or automate actions beyond their role. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats access enforcement as a core control family issue, not a cosmetic application-layer check. In mature environments, the hard part is not proving who someone is, but continuously proving what they are allowed to touch as context changes.
In practice, many security teams encounter this only after an authenticated user has already moved laterally across objects or functions that were never meant to be reachable.
How It Works in Practice
Weak authorisation usually shows up when an application trusts user-provided identifiers, role claims, or hidden fields without re-checking entitlement at the object, action, or workflow level. A user may be logged in correctly, yet still be able to swap an account ID in a request, submit a form field that should be server-controlled, or call an endpoint that was exposed to the UI but never constrained in the backend. The result is not an authentication failure. It is an access decision failure.
Good practice is to evaluate authorisation at the point of use, not just at the point of login. That means checking three things consistently: whether the subject can access this object, whether the subject can perform this action, and whether the action is still allowed in the current context. This is especially important for APIs, microservices, and agentic workflows where no browser UI exists to enforce a front-end boundary. The ISO/IEC 27001:2022 Information Security Management model supports this by requiring systematic control selection, ownership, and review rather than relying on assumed application safety.
- Use server-side checks for every sensitive object and operation, even when the caller is authenticated.
- Prefer deny-by-default rules and explicit allow lists for actions, tenants, and records.
- Keep role logic separate from object ownership logic, because role membership alone is rarely enough.
- Prevent mass assignment by rejecting unexpected fields instead of trusting client-side payloads.
- Log denied access attempts, but do not treat logging as a substitute for enforcement.
For APIs, this often means tying each request to a verified entitlement, not simply a session token. For non-human identities, service accounts, and agents, the same rule applies: an authenticated credential should be able to do only what its scoped policy permits, with no hidden inheritance from a broader deployment role or shared secret. These controls tend to break down when legacy applications depend on client-side enforcement, because the backend inherits trust that was never validated server-side.
Common Variations and Edge Cases
Tighter authorisation often increases development and policy maintenance overhead, requiring organisations to balance granular control against delivery speed. That tradeoff becomes more visible in multi-tenant platforms, delegated administration, and workflows where users legitimately need temporary elevation. Current guidance suggests that just-in-time approval and context-aware policy reduce exposure, but there is no universal standard for how granular every control must be in every application.
Edge cases often include indirect object references, shared records, background jobs, and agent-driven automation. In those environments, the caller may be authenticated once and then operate across multiple resources unless each downstream hop revalidates the entitlement. This is particularly dangerous when services trust upstream claims without checking tenancy, ownership, or workflow state. Teams should also watch for permission drift, where a role remains technically valid long after business responsibilities changed.
Where identity governance intersects with API design, the issue becomes more than a coding flaw. It is a control design problem that can affect privileged access, non-human identities, and delegated administration alike. Security teams should test not only whether the right identity can log in, but whether the right identity can still act after token reuse, role changes, and object substitution. That is where broken authorisation usually survives basic authentication tests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Weak authorisation is an access control failure within the CSF protect function. |
| NIST AI RMF | If APIs front AI services, authorisation also governs who can invoke or alter model outputs. | |
| OWASP Non-Human Identity Top 10 | Service accounts and tokens need scoped entitlements, not just valid authentication. | |
| OWASP Agentic AI Top 10 | Autonomous agents can misuse authenticated access if action-level controls are weak. | |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement is the core control that fails when auth is correct but authz is weak. |
Enforce least privilege with backend checks on every protected resource and function.
