Because the application often checks identity at login but fails to bind that identity to the object or action being requested at runtime. Attackers can change object identifiers, call hidden routes directly, or repeat privileged requests from an authenticated session. The failure is server-side authorisation, not user-interface masking.
Why Broken Authorization Keeps Reappearing in APIs
Broken object and function authorisation keep showing up because modern APIs expose far more direct server-side attack surface than traditional page-based applications. The login may be correct, but the request still reaches a resource or action the caller should not control. Once a client can guess or modify object IDs, invoke hidden endpoints, or replay a valid request pattern, the server becomes the real enforcement point, and that is where the control usually fails.
This problem persists because teams often test the “happy path” rather than every object, method, and tenant boundary. API gateways, front-end restrictions, and mobile app screens can create a false sense of safety when the backend still trusts client-supplied identifiers or assumes that a logged-in user may perform any action exposed by the route. The weakness is architectural, not cosmetic, which is why it survives UI rewrites and redesigns. In practice, many breaches are discovered only after an authenticated user finds a request the system never re-checks at the object or action level.
How It Works in Practice
Broken object authorisation usually appears when the server accepts an identifier, then fetches or updates the referenced record without verifying that the caller is entitled to that exact object. Broken function authorisation is similar, but the failure is at the action level: a user may be allowed into the application while still being able to call an administrative, financial, support, or internal function that should have been blocked.
- Object-level failures often involve predictable IDs, sequential records, or tenant-scoped data that is never revalidated server-side.
- Function-level failures often involve hidden routes, undocumented API methods, or role checks that exist in the client but not in the backend.
- Both failures are worse when the API assumes “logged in” means “allowed to do anything related to the session.”
The practical test is simple: authentication answers “who are you?”, but authorisation must answer “which object, which action, and under what constraint?”. If the answer is derived from the request body, URL path, or client-side logic alone, the control is fragile. Strong implementations bind the caller’s identity and privilege to each request on the server, enforce ownership or role rules centrally, and treat every object lookup or state-changing action as a fresh decision.
Current guidance generally favours deny-by-default server checks, explicit action scoping, and object-level ownership validation, especially where APIs serve multiple apps, tenants, or partner integrations. NIST SP 800-53 Rev. 5 Security and Privacy Controls is useful here because it reinforces access enforcement, least privilege, and privileged action control at the system boundary. This guidance breaks down most often when legacy endpoints, internal admin functions, or high-volume batch APIs bypass the same policy path as user-facing requests.
Common Variations and Edge Cases
Tighter authorisation often increases implementation overhead, because every object class and every sensitive function needs explicit server-side policy rather than a single coarse role check. That trade-off is worth it, but the right design depends on whether the API is single-tenant, multi-tenant, or exposed to partners, because the blast radius of a mistake changes sharply across those environments.
One common edge case is “same role, different scope”, where two users share the same application role but must not see each other’s records. Another is service-to-service API access, where internal callers are assumed trusted and therefore receive broad permissions that no human user would get. A third is admin-by-API behaviour, where hidden endpoints are documented nowhere but remain reachable if the method and path are known. In all three cases, the failure is not the presence of an endpoint, but the absence of a server-enforced decision about who may use it and on what object.
The 52 NHI breaches Report is useful as a broader reminder that weakly governed machine access often turns into repeated abuse, and that pattern matters here because api authorisation failures frequently scale through automated callers. The edge case most teams underestimate is that “internal only” routes are often the easiest place for broken function checks to survive because they are tested least and abused longest.
Risk and Threat Considerations
Broken object and function authorisation create direct exposure to data theft, privilege abuse, fraud, and tenant cross-over. Because the caller is already authenticated, attackers do not need to defeat login controls, they only need to find a request that the application fails to re-authorise at the object or action level.
Failure mechanism: The attacker changes an object reference, reuses a valid session, or invokes a hidden function that the backend does not independently constrain. This is a classic server-side access-control failure, and it becomes especially dangerous when APIs expose predictable identifiers, reusable request patterns, or privileged operations without a second policy check.
Impact: Sensitive records can be read or modified, administrative functions can be called from low-privilege sessions, and one compromised account can be turned into broad business impact across users, tenants, or operational workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | API object and function checks depend on enforcing access decisions correctly. |
| Recommendation — Enforce server-side access decisions for every API object and action. | ||
| CIS Controls v8 | 6 — Access Control Management | Broken authorisation is an access-control failure across API endpoints and functions. |
| Recommendation — Restrict each API endpoint and object to the minimum required access. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Attackers abuse public APIs by calling exposed objects and functions directly. |
| Recommendation — Hunt for direct abuse of exposed API routes and parameters. | ||
Practitioner Guidance
What to verify: Confirm that every sensitive API request is authorised at the object and function level on the server, not inferred from the client, route visibility, or front-end state. The practical check is whether changing a record ID, method, or hidden endpoint still leaves a request blocked for an unentitled caller.
Decision rule: If a request can change data, expose another user’s record, or invoke an administrative action, treat it as a separate authorisation decision even when the caller is authenticated. Do not accept “the UI does not show it” as evidence of safety.
Practitioner takeaway: API breaches keep recurring here because authentication is being treated as the finish line; the control only works when each object and each action is re-validated at the server boundary every time.
Related resources from NHI Mgmt Group
- Why do API gateways struggle with broken object level authorisation?
- Why do broken object level authorization issues keep appearing in API programs?
- Why do weak passwords keep causing breaches even when users are trained?
- What breaks when API authorisation only protects the object and not its fields?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
