At a glance
- Broken access control is when users or processes can act outside their intended permissions.
- It is A01, the #1 risk in the OWASP Top 10:2025, and OWASP found some form of it in 100% of the applications tested.
- In hybrid and multi-cloud estates, it usually stems from over-permissioned identities, static roles and inconsistent enforcement.
- Prevention means continuous authorization: just-in-time, least-privilege access governed across every cloud.
In November 2025, OWASP released the 8th edition of the Top 10, the OWASP Top 10:2025, with a few changes worth checking out. However, few security leaders will be surprised to see Broken Access Control once again claims the number-one spot. Despite major advances in authentication, encryption, and cloud-native security tooling, unauthorized access remains the single most exploited weakness in modern infrastructure.
Why Broken Access Control Persists
At first glance, this seems like a purely developer-owned issue allowing users or processes to act outside their intended permissions (as per the OWASP definition). OWASP broken access control is catalogued as A01:2025 and holds the #1 spot again, with Server-Side Request Forgery (SSRF) now rolled into the category. OWASP found some form of broken access control in 100% of the applications it tested for the 2025 edition. But the reality is broader; in multi-cloud and hybrid environments, access control failures usually stem from the complex web of identities, roles, and permissions that govern infrastructure-level access across CSP and on-prem systems. With consistent enforcement challenging within and across these heterogeneous environments, it’s worth exploring why broken access control persists:
1. Over-permissioned identities
Cloud service providers each have their own identity and access management (IAM) model: AWS IAM policies, Azure AD roles, custom RBAC systems for Kubernetes clusters, and on-prem directories for legacy workloads. As identities span these boundaries, permissions multiply. “Temporary” elevated access often becomes permanent, and the concept of least privilege erodes over time.
2. Static permissions in dynamic environments
Cloud infrastructure is ephemeral. Compute instances spin up and down, containers redeploy hourly, and workloads migrate between data centers and clouds. Yet access policies are often static: long-lived roles or group memberships that were designed for fixed servers. This mismatch between dynamic infrastructure and static entitlements leaves wide gaps for abuse.
3. Inconsistent enforcement across clouds
Each provider interprets access policies differently. An Azure AD conditional-access policy may not translate cleanly into AWS IAM conditions or an on-prem LDAP group. The result is fragmented enforcement. A principle of least privilege in one environment becomes a loose approximation in another.
4. Limited visibility into effective access
Ask any security leader a deceptively simple question: who can access what, right now? And you’ll likely find that few can answer confidently. Without continuous visibility into existing entitlements, drift and misconfigurations remain hidden until an attacker exploits them.
Identity has become the connective tissue between environments. Each user, service account, workload identity, or API key can bridge clouds, linking production systems, CI/CD pipelines, and on-prem management planes. Compromise one of those identities, and lateral movement across environments becomes trivial. These are not authentication failures. They occur after login, when authorization and entitlement enforcement fail. In other words, Broken Access Control in a multi-cloud world is the failure to govern what authenticated identities can actually do.
Broken access control examples: app layer and cloud
These broken access control examples pair OWASP’s A01:2025 list with what broken access control in the cloud looks like at the identity layer.
| Example (OWASP A01:2025) | What it looks like in an app | Cloud and identity equivalent |
| Violating least privilege or deny by default | Access available to anyone instead of to specific roles | “Temporary” elevated access that quietly becomes permanent |
| Accessing another user’s account by changing its identifier | Editing an ID in a URL or API call to view someone else’s record | A role or group that can read far more data than any one task needs |
| Missing access controls on APIs | POST, PUT or DELETE calls that skip authorization | Service accounts and API keys holding broad standing permissions |
| Privilege escalation | Acting as an admin while logged in as a user | Identities accumulating admin rights through overlapping roles across AWS IAM, Azure AD and Kubernetes RBAC |
| Server-Side Request Forgery (now in A01) | A server tricked into requesting internal resources | A workload used to reach internal services with its own identity’s permissions |
From Authentication to Authorization Governance
Identity security has traditionally focused on authentication, verifying who someone is. But the persistence of Broken Access Control as a risk factor shows that the real challenge is authorization: continuously verifying what that identity can do across systems.
Broken access control prevention still starts with OWASP’s app-layer fixes: deny by default, reuse one access control mechanism across the application and log access control failures. In cloud and hybrid estates, it also means governing what identities can do in every environment.
To address this, security teams must evolve from identity verification to runtime entitlement governance. That shift involves three key changes:
Just-in-time and just-enough access
Replace long-lived admin roles with ephemeral privileges granted only when needed. Access should be time-bounded, scope-limited, and automatically revoked.
Continuous visibility and analysis
Quarterly reviews aren’t enough. Entitlements must be continuously discovered and analyzed across AWS IAM, Azure AD, Kubernetes RBAC, and on-prem directories to detect drift, privilege creep, and toxic combinations while accelerating critical audits.
Automated least-privilege enforcement
Use automation, policies and native workflows to accelerate approval and access processes. Manual approvals and spreadsheets can’t keep up with the pace of change and developer needs in these cloud-native and hybrid environments.
Key takeaways
- Replace standing admin roles with just-in-time, just-enough access that expires on its own.
- Discover and analyze entitlements continuously, and automate least-privilege enforcement instead of relying on quarterly reviews.
- Keep OWASP’s app-layer fixes, then extend prevention to what authenticated identities can do across every cloud.
- In hybrid cloud, broken access control comes from over-permissioned identities, static roles, inconsistent enforcement and poor visibility.
- That is why it remains A01 and the #1 risk in the OWASP Top 10:2025.
Summary
For organizations operating in cloud and hybrid estates, Broken Access Control remains the most significant security risk. This isn’t because teams ignore it, but because traditional IAM tools were never built for this modern cloud landscape.
OWASP’s 2025 list reinforces a truth every security leader now faces: protecting the enterprise means protecting access at runtime, not just credentials at login. Until identity and entitlement governance operate continuously across AWS, Azure, and on-prem systems, Broken Access Control will stay at the top and adversaries will keep exploiting the gap between authorization and access.
Frequently asked questions
Why does broken access control still top the OWASP Top 10?
Broken access control still tops the OWASP Top 10 because most applications and cloud environments still rely on coarse, standing permissions instead of continuous authorization checks.
What does broken access control mean for identity security in hybrid cloud?
Broken access control in hybrid cloud means identities can reach data or systems beyond their intended scope, often due to inconsistent policy across environments.
How do over-permissioning and standing access lead to broken access control?
Over-permissioning and standing access lead to broken access control by leaving permissions active and unreviewed well beyond what any task actually requires.
How does P0 Security enforce least privilege to prevent broken access control?
P0 Security enforces least privilege to prevent broken access control by scoping every identity’s permissions to the specific task at hand, in real time.
What are common examples of broken access control?
Common examples of broken access control include changing an ID in a URL or API call to view another user’s record, API endpoints that skip authorization on POST, PUT or DELETE calls, service accounts holding broad standing permissions and temporary elevated access that quietly becomes permanent.
What is A01 broken access control in the OWASP Top 10:2025?
A01:2025 Broken Access Control is the #1 risk in the OWASP Top 10:2025, covering any failure that lets users or processes act outside their intended permissions, now including Server-Side Request Forgery (SSRF), with 40 CWEs mapped to the category.