Broken access control still exposes modern application authorization

At a glance

What this is: OWASP Top 10 2025 keeps broken access control at number one, showing that ad hoc authorization patterns still fail in modern application estates.

Why it matters: IAM, PAM, and NHI programmes all depend on trustworthy authorization boundaries, so broken access control directly affects how teams govern users, workloads, and machine identities.

By the numbers:

• Broken Access Control maintains its position at #1 as the most serious application security risk, and on average 3.73% of applications tested had one or more of the 40 CWEs in this category.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Cerbos' analysis of OWASP Top 10 2025 and broken access control

Context

Broken access control is what happens when a system lets a subject act on data or functions it should not reach. In practice, that usually means authorization is scattered across application code, tied to brittle role checks, or assumed to be correct because the interface is internal.

For IAM teams, the issue extends beyond web applications. The same weak authorization patterns show up in workload access, service-to-service calls, and machine identity governance, where privilege boundaries are often defined once and then left to drift.

As architectures expand into microservices, multitenancy, APIs, and machine identities, the access-control surface grows faster than the governance model around it. That is why this topic remains central to both application security and identity security programmes.

Key questions

Q: How should security teams prevent broken access control in modern applications?

A: Security teams should move authorization out of scattered code and into a centrally governed policy model. That approach makes access rules consistent across services, easier to test, and easier to audit. It also reduces the risk that different teams will implement conflicting permission logic for the same resource or action.

Q: Why do microservices and APIs make broken access control harder to control?

A: Microservices and APIs multiply the number of places where authorization can fail. When permission logic is duplicated across services, the same user or machine identity can be treated differently depending on which endpoint it reaches. That creates drift, weak auditability, and a much larger attack surface.

Q: What do security teams get wrong about machine identities and authorization?

A: They often treat machine identities as infrastructure details rather than authorization subjects. In practice, service accounts and API keys can carry broad, durable access that never gets re-evaluated. That means broken access control can spread from one application bug into a broader privilege problem across workloads.

Q: What should teams do when broken access control keeps appearing in audits?

A: Teams should stop treating the finding as a code-quality issue and treat it as a governance issue. The practical response is to standardise authorization policy, review high-risk resources and identities together, and require evidence that decisions are consistent, logged, and versioned across the environment.

Technical breakdown

Why ad hoc role checks keep failing

Broken access control persists when authorization is embedded directly in application logic through if-else checks, static role gates, or duplicated permission code. Those patterns are hard to review, easy to bypass, and difficult to keep consistent across services. They also break down when a single resource must be evaluated against ownership, tenant, region, or business threshold. Once the logic is spread across teams and repositories, enforcement becomes inconsistent and audit evidence becomes weak.

Practical implication: centralise authorization decisions so review, testing, and audit trails all point to one control plane.

How policy-based authorization changes the control model

Policy-based authorization separates the decision from the application. A policy decision point evaluates user, resource, action, and context, then returns allow or deny based on explicit rules. This approach supports least privilege and deny-by-default more reliably than embedded checks because the decision logic is versioned, reviewable, and reusable. It also makes it easier to express object-level controls, where access depends on who owns the resource and under what conditions it may be used.

Practical implication: define a policy model that covers ownership, context, and tenant boundaries before scaling new services.

Why machine identities make broken access control harder to contain

Machine identities expand the authorization problem because service accounts, API keys, tokens, and workload identities can hold broad permissions across systems. If those identities are over-privileged or poorly scoped, the same broken access pattern becomes a cross-environment issue rather than a single application bug. In identity terms, the control failure is not just who can log in, but what a non-human identity can do after authentication. That shifts attention from access checks at the front door to authorization at every invocation point.

Practical implication: treat machine identity permissions as part of the same authorization architecture as human access and review them together.

Threat narrative

Attacker objective: The attacker objective is to reach data or functions beyond the intended authorization boundary by exploiting weak or inconsistent access control.

1. Entry occurs when an application exposes an object, API action, or service endpoint without a robust authorization check tied to the requester’s identity and context.
2. Escalation happens when the attacker or unauthorised user pivots from one allowed action to broader object tampering, force-browse behaviour, or parameter manipulation across services.
3. Impact follows when the missing control lets the subject read, change, or delete data outside its intended boundary, turning a local access flaw into data exposure or privilege abuse.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Broken access control is now an identity governance problem, not just an application defect. The article shows that authorization failures survive because teams still treat access checks as local implementation details instead of governed policy. That is why modern IAM, PAM, and NHI programmes need a single authorization model that can be reviewed across humans, workloads, and service boundaries. Practitioners should treat authorization as a control architecture, not a coding pattern.

Policy-driven authorization is the right response because it makes control decisions auditable. When permissions are expressed centrally, the organisation can test, version, and certify them in a way that scattered code branches cannot support. That matters for compliance evidence as much as it matters for security, because auditors need to see who can do what, under which conditions, and why. Practitioners should align application authorization with governance workflows, not leave it to engineering folklore.

Machine identities magnify broken access control because over-privilege turns one mistake into systemic exposure. Service accounts and API keys often inherit broad access that was never revisited after deployment. In NHI terms, that is not a one-off exception, it is privilege drift with a long tail. Practitioners should review machine identity permissions as part of the same authorization regime used for human access.

Least privilege cannot be sustained when authorization logic is duplicated across microservices. The article’s emphasis on complex architectures is a warning that distributed checks erode consistent enforcement. Once different teams encode different interpretations of the same rule, governance breaks at the seams. Practitioners should assume that duplicated logic will diverge and design for a single source of authorization truth.

Central governance is the named concept this article reinforces. Broken access control persists because access decisions are too often embedded where they are hardest to govern. A central policy model is not just cleaner engineering, it is the only practical way to make authorization reviewable at enterprise scale. Practitioners should use the OWASP Non-Human Identity Top 10 and the NHI Lifecycle Management Guide to align policy with identity lifecycle controls.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91% of organisations have experienced secrets leaks in some form, according to NHI Mgmt Group research.
• For lifecycle control detail, see NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding patterns that make authorization governable at scale.

What this signals

Central policy is becoming the practical dividing line between scalable authorization and security debt. As applications spread across services and machine identities, the question is no longer whether access checks exist, but whether they are governable across the full lifecycle of the identity.

If your programme still depends on scattered role logic, expect more review friction, more inconsistent decisions, and weaker audit evidence. The better signal is whether one policy model can govern human users, service accounts, and workload access without code-level exceptions.

The governance implication is clear: broken access control should be tracked alongside identity lifecycle and privilege management, not left only to application security teams. That means aligning access review, offboarding, and policy testing to the same control surface.

For practitioners

• Inventory every inline authorization check Map all if-role checks, object ownership checks, and parameter-based access rules across applications and services. Flag any endpoint where the same access decision appears in multiple code paths, because duplication is where drift starts.
• Move access decisions into a central policy model Define resource types, actions, tenants, ownership attributes, and contextual inputs in one policy layer so each service asks the same decision point. That lets teams test and version authorization independently of application releases.
• Treat machine identities as first-class authorization subjects Review service accounts, API keys, tokens, and workload identities alongside human roles. Remove broad permissions that exist only because the credential was created for convenience and never re-scoped after deployment.
• Build audit evidence around decisions, not code paths Capture policy decisions, denied requests, and the attributes that drove each outcome. This creates a defensible record for pentests and reviews, instead of forcing security teams to reconstruct intent from application code.

Key takeaways

• Broken access control remains a top risk because authorization is still too often embedded in fragile application logic.
• The scale of the problem is visible in OWASP’s 3.73% finding, which shows the issue persists across tested applications.
• The practical fix is central policy governance for both human and machine identities, with auditable decisions and lifecycle control.

Key terms

• Broken Access Control: A failure in which a system allows a user or machine identity to perform actions outside its intended permissions. The problem is usually caused by missing, inconsistent, or duplicated authorization logic, which makes enforcement difficult to govern and easy to bypass.
• Policy-based Authorization: An access control model where decisions are made by centrally defined policies rather than scattered application code. The policy evaluates identity, resource, action, and context, which makes the control more consistent, auditable, and easier to apply across services and machine identities.
• Machine Identity: A non-human identity used by software, services, workloads, or automation to authenticate and access resources. In governance terms, machine identities must be treated as access subjects with scope, ownership, and lifecycle controls, not as technical infrastructure details.
• Object-level Authorization: A control that decides whether a subject can access a specific record, file, or resource instance. It is more precise than role-only checks and is commonly used to prevent unauthorized reading, updating, or deletion when users or machines should only touch their own objects.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: OWASP Top 10 2025 and broken access control. Read the original.