It fails when the application checks that a user is logged in but does not reliably check whether that user is allowed to reach a specific object, action, or administrative function. That gap lets one account act on another user’s data or cross a privilege boundary without breaking the login flow.
Where broken access control fails in practice
broken access control usually fails at the authorization boundary, not the login boundary. The application accepts that a user is authenticated, then skips or weakens the check that ties the requested object, action, or admin function to that user’s actual rights. The result is horizontal access to another user’s data, or vertical access to a higher-privilege function.
Why authentication is not enough
Many teams assume a successful sign-in is the main gate. In practice, that only proves the session belongs to some valid account. The failure appears when the application does not enforce per-request authorization on the specific record, API operation, or workflow step being accessed. That is why an attacker can keep a legitimate session and still cross a boundary they should never reach.
Common examples include changing an identifier in a URL or request body, replaying a hidden admin endpoint, or calling an API function that was protected in the UI but not on the server. The weakness is structural: access decisions are made too early, too loosely, or only in one part of the stack.
The most useful mental model is to separate identity from entitlement. Identity answers who the caller is; authorization answers what that caller may do right now. Broken access control appears when those two questions are treated as interchangeable, or when the check exists but is incomplete, inconsistent, or bypassable through an alternate code path.
Where the gap shows up in object, function, and role checks
In practice, broken access control tends to show up in three places. First, object-level access fails when the backend does not verify ownership or tenancy before reading or writing a record. Second, function-level access fails when an ordinary user can reach an admin-only action through a direct API call, background job, or undocumented route. Third, role or policy checks fail when the application trusts client-side controls, cached decisions, or stale entitlements instead of re-evaluating authorization at the point of use.
That is why secure design has to cover the full request path, not just the front door. The check must be attached to the resource and operation the caller is trying to use, and it must be enforced by the server side control point that actually releases the data or executes the action.
Practically, this is where Authorisation Models Guide helps distinguish coarse role checks from policy-driven access decisions, and IAM and IGA Basics reinforces the difference between having an account and having the entitlement to use a protected function.
Risk and Threat Considerations
Broken access control is dangerous because the attacker often does not need to defeat authentication, only to reuse a valid session against a weaker authorization path. That makes abuse quieter than a login bypass and harder to spot in telemetry, especially when requests look like normal user activity but target another tenant, record, or privilege boundary.
Failure mechanism: The application enforces authentication but not reliable authorization at the object, action, or workflow level, so a caller can change an identifier, invoke a hidden endpoint, or reuse a role that is broader than intended.
Impact: The result can be data exposure, unauthorized modification, privilege escalation, and cross-account access that undermines tenant isolation and trust in the application’s control model.
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 OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Broken access control is fundamentally an authorization failure across objects and functions. |
| Recommendation — Enforce server-side authorization checks for every sensitive object and function. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The issue is failure to enforce permitted access to objects and actions. |
| AC-6 — Least Privilege | Overbroad access makes broken access control easier to exploit and more damaging. | |
| Recommendation — Apply access enforcement at the resource and operation level. Restrict permissions to the minimum needed for each account and process. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Object-level ID tampering is a classic practical form of broken access control. |
| API5 — Broken Function Level Authorization | Unauthorized admin or sensitive actions are another common failure mode. | |
| Recommendation — Validate object ownership and tenancy on every API request. Protect sensitive functions with server-side authorization checks. | ||
Practitioner Guidance
What to verify: Test authorization on the server side for every sensitive object and action, not only on the page or UI path. A request should fail even when it is replayed directly, the identifier is changed, or the user reaches the function through a different route.
Common mistake: Treating “logged in” as a pass condition for access. If the application uses roles, ownership, scopes, or policy rules, confirm that those checks are evaluated at the point of use and are consistent across all code paths.
Practitioner takeaway: Broken access control is usually a missing or inconsistent entitlement check, so the real question is whether the backend can prove, on every request, that this caller is allowed to act on this specific thing.
Related resources from NHI Mgmt Group
- Why does role-based access control often fail in practice?
- When does policy-based access control fail for workloads and agents?
- What is the difference between broken access control and security misconfiguration in NHI environments?
- Why do permission boundaries fail as a scale control for cloud access?
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 October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org