A failure in which an API allows a caller to access data or functions outside its permitted scope. The problem can appear as object-level or function-level abuse, and it often survives if teams only test happy-path behaviour.
Broken Authorisation in APIs
Broken authorisation is an API security failure where the server does not consistently enforce what the caller is allowed to see or do. It usually shows up when object references, function calls, or property changes are checked too loosely, especially across different roles or tenants.
At a practical level, this term covers a family of access-control mistakes rather than a single bug. A caller may be able to read another user’s record, change fields that should be locked down, or invoke a function that was never intended for that access level. The problem often appears in the gap between what the client interface suggests and what the backend actually enforces.
Common variants include object-level failures, where a caller can act on an object it should not reach, and function-level failures, where a caller can trigger an action outside its entitlement. The API Security Top 10 formalises this as broken object and function authorization, which is why the term is often used as a shorthand for broader access-control weaknesses in API design and implementation. OWASP API Security Top 10
Good implementations treat authorisation as a server-side obligation on every sensitive request, not as a one-time login outcome. That means the policy must be evaluated against the specific resource, action, and caller context each time, including cases where the caller is authenticated but still not entitled to the requested operation. Authorisation Models Guide
Why It Happens
Broken authorisation usually emerges when teams rely on coarse role checks, trust client-side state, or assume that an authenticated user can safely reuse another user’s request pattern. It also appears when permission logic is scattered across handlers instead of enforced in a single, testable control point.
Another common cause is mismatch between business intent and implementation detail. A product team may intend one user to manage only their own records, but the API accepts identifiers, filters, or action flags that let the caller step outside that boundary. This is why happy-path testing misses many defects: the dangerous path is often one parameter change away from the expected request.
In more mature environments, the failure is not only in code, but in policy design. Weak entitlement models, ambiguous ownership of resources, and inconsistent permission inheritance can all make it easy for developers to ship endpoints that look correct in normal use but fail under adversarial input. IAM and IGA Basics
Security Consequences
The direct consequence is unauthorised access to data or functions, which can quickly become confidentiality, integrity, or transaction-risk exposure. In an API context, one weak endpoint can expose entire datasets, allow privilege escalation within an application, or create an unintended path to administrative action.
Broken authorisation is especially dangerous in systems that expose many resources through a shared API surface, because a single logic flaw can scale across many records, tenants, workflows, or integrated services. If an API is used by automation, partner systems, or agentic workflows, the blast radius can grow further when overbroad access is reused repeatedly. AI Agent Authorisation Guide
From an operator’s perspective, the most serious failure is not just data exposure, but trust collapse. Once authorisation cannot be relied on, downstream controls such as audit logging, abuse detection, and least-privilege design become harder to interpret because the system no longer has a stable boundary for legitimate access. Permission-Aware RAG Guide
How To Recognise and Test It
Broken authorisation is best identified by asking whether the same endpoint behaves differently when the caller changes identity, scope, tenant, or role, but the request shape stays the same. The key test is not whether the request succeeds in the normal case, but whether the server still blocks it when the caller should have no relationship to the target object or function.
Effective testing includes direct object access attempts, role switching, parameter tampering, and negative testing of sensitive functions. A well-designed test suite should verify both object-level and function-level restrictions, because one can fail even when the other appears sound. Role Mining and Role Design Guide
For teams that use policy-driven access control, the practical check is whether authorisation decisions are explicit, repeatable, and tied to the action being requested. If the policy cannot explain why a request is allowed or denied in a specific context, the implementation is usually too weak to trust at scale.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Defines object-level API access failures central to broken authorisation. |
| API5 — Broken Function Level Authorization | Covers API actions exposed beyond the caller’s permitted functions. | |
| API3 — Broken Object Property Level Authorization | Captures property-level overreach when callers can modify fields they should not control. | |
| Recommendation — Test every object reference server-side and deny requests that target resources outside the caller’s scope. Enforce function-level checks on every sensitive endpoint before executing the action. Validate per-field write permissions so callers can only change properties they are entitled to edit. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Requires limiting access to only the permissions needed for the task. |
| IA-5 — Authenticator Management | Supports safe handling of credentials that gate API access and scoped entitlement use. | |
| Recommendation — Restrict API permissions to the minimum set needed for each role, service, or integration. Manage API credentials with rotation and revocation so stale access does not outlive its entitlement. | ||