Why does broken access control happen even when login works correctly?

Why This Matters for Security Teams

broken access control is one of the most common ways authenticated users end up doing things they were never meant to do. The login step only confirms that a user, service account, or application has a valid credential. It does not prove the requested action is appropriate. OWASP highlights access control as a persistent weakness in application security, and NIST control guidance treats authorization as a separate requirement from authentication in NIST SP 800-53 Rev 5 Security and Privacy Controls.

That distinction matters because attackers do not need to bypass login if they can reuse legitimate access paths, tamper with object references, or reach code paths that never check policy. In NHI environments, the same pattern shows up with service accounts, API keys, and automation identities that authenticate correctly but retain broad permissions. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which turns a working login into a potential breach path when authorization is weak or inconsistent.

In practice, many security teams discover broken access control only after a user, bot, or integration has already reached data or functions that were assumed to be protected.

How It Works in Practice

Authorization should happen after authentication and before every sensitive action, not just once at session creation. The application must verify who is acting, what object or resource is being targeted, and whether the action is allowed in that specific context. This is why static allowlists and front-end checks are insufficient: the browser can be modified, APIs can be called directly, and backend services can be chained in ways the user interface never intended.

OWASP’s OWASP Non-Human Identity Top 10 is useful here because many authorization failures involve machine identities rather than people. A service account may authenticate successfully to a database, queue, or internal API, but still need per-request policy checks to stop it from reading another tenant’s records or invoking an admin-only function. NHIMG’s 52 NHI Breaches Analysis shows how often compromise paths begin with valid credentials that were overtrusted by the application.

• Enforce server-side authorization on every sensitive route, method, and object.
• Use deny-by-default policy decisions, then grant only the minimum action required.
• Check ownership, tenant scope, and role or attribute context before returning data.
• Apply the same policy logic across UI, API, background jobs, and internal services.
• Log authorization failures separately from authentication failures to spot abuse patterns.

For NHI and API workloads, pair authorization with short-lived credentials, secret rotation, and workload identity so a valid credential does not become a standing pass. These controls tend to break down when legacy code paths or internal service-to-service calls skip the central policy layer because the application assumes authenticated equals authorized.

Common Variations and Edge Cases

Tighter authorization often increases application complexity, so teams must balance safety against developer speed and operational overhead. That tradeoff becomes visible in systems with shared objects, nested roles, or delegated administration, where a single policy model may not cover every resource consistently.

There is no universal standard for this yet, but current guidance suggests using centralized policy-as-code and runtime evaluation instead of scattering access rules across controllers and business logic. The same principle appears in Ultimate Guide to NHIs — Key Challenges and Risks, especially where excessive privilege and poor visibility make authorization drift hard to detect. For implementation, CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management both support least privilege and access review discipline, but they do not remove the need for code-level checks.

• Object-level authorization failures often hide behind valid session tokens and correct role membership.
• Service-to-service calls are especially risky when internal trust is assumed instead of verified.
• Role-based access can be too coarse when a user should access one record, not an entire dataset.
• Temporary exceptions, break-glass access, and admin impersonation need explicit expiry and audit trails.

In practice, broken access control is usually not a login problem at all. It is a policy enforcement problem that surfaces when code paths, APIs, or machine identities are trusted more than the authorization layer.

Related resources from NHI Mgmt Group

• Why does broken access control persist even when IAM policies exist?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• What is the difference between broken access control and security misconfiguration in NHI environments?