Where does broken access control fail in practice?

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.