API Authorization Flaw

What the flaw is in practice

An API authorisation flaw is not a failure of reachability or transport, but of decision-making at the server. The endpoint is callable, yet the server does not correctly verify whether the caller may read that object, invoke that function, or use that scope. In practice, this is the difference between a request that is syntactically valid and one that is actually entitled.

These flaws often sit in the gap between authentication and authorisation. A token may be real, but still over-scoped; a session may be active, but not entitled to a different tenant’s record; a low-privilege caller may be able to trigger an administrative action because the server trusts client-side state or a guessed identifier.

Common failure patterns

The most familiar patterns are broken object-level authorisation, broken function-level authorisation, and broken property-level checks. Each one removes a different server-side guardrail: object checks protect specific records, function checks protect sensitive actions, and property checks protect which fields or parameters a caller may set or view.

These problems are especially dangerous because they can look like ordinary successful API calls in logs. A request may return a normal response code, no error may be raised, and the only difference may be that the caller accessed data or actions outside its intended trust boundary. That makes the flaw easy to miss during superficial testing and easy to automate at scale.

Why it matters for API security

API authorisation flaws undermine the core assumption that the server is the policy enforcement point. When authorisation is missing, inconsistent, or applied only in some code paths, attackers can move from one object to another, from one function to another, or from read access to modification. The result is often horizontal privilege abuse, vertical privilege escalation, data exposure, or unauthorised business action.

OWASP API Security Top 10 places broken authorisation at the center of API risk because it is a recurring source of real-world compromise. For teams building policy-driven APIs, Authorisation Models Guide helps frame how role, attribute, relationship and policy-based decisions should be applied to API requests, while OpenID AuthZEN Authorization API Guide shows how to externalise and standardise those decisions between a policy decision point and the API enforcement layer.

How teams prevent and verify it

Prevention starts with treating authorisation as a server-side control on every sensitive request path, not as a front-end hint or a one-time gateway check. APIs need consistent decisions for object access, action access and field-level access, plus clear handling for multi-tenant boundaries, delegated access and token scopes.

Verification should include negative tests that try to cross object boundaries, invoke restricted functions and submit disallowed properties. Authorisation Testing Automation Guide is a useful companion for building regression checks that catch BOLA, BFLA and BOPLA patterns before release. Where APIs rely on externalised policy, Externalised Authorisation Buyer's Guide is a practical reference for evaluating policy-engine behaviour, failure modes and rollout concerns.

At the platform level, teams also need inventory and review discipline. IAM and IGA Basics is relevant when API access is tied to user, service or machine entitlements, because excessive privileges, stale access and weak governance often become the hidden cause of API authorisation failures.

Risk and Threat Considerations

API authorisation flaws create direct exposure because they let an attacker turn a valid request path into unauthorised access. The danger is not just data disclosure, but the ability to enumerate objects, alter records, trigger functions and chain low-friction calls into broader compromise.

Failure mechanism: The server accepts a request before it has proved that the caller may act on that specific object, function or field, so a valid token becomes enough to cross a trust boundary.

Impact: Attackers can read or change other users’ data, abuse admin-only actions, bypass tenant isolation, and in some environments pivot from a single bad endpoint to full account, workflow or data-set compromise.

Practitioner Guidance

What to watch for: Treat every API route that exposes object IDs, action parameters or writable properties as an authorisation decision point. If a request succeeds only because the caller supplied a token, without a fresh server-side entitlement check, the endpoint deserves scrutiny.

Governance implication: Ownership should sit with the API team that controls the enforcement logic, not with the client application that calls it. The safest programmes make authorisation rules testable, reviewable and consistent across services, rather than embedded ad hoc in endpoint code.

Related resources from NHI Mgmt Group

• Authorization Flaw
• API Authorization
• Authorization
• Who should be accountable when an API authorization flaw survives an update and reaches a live subdomain?