Notifications
Clear all
Topic starter
11/06/2026 11:02 pm
TL;DR: Broken Access Control remains OWASP’s top application security risk, with OWASP reporting that only 3.73% of tested applications had one or more CWEs in the category, underscoring how fragile authorization still is across microservices, APIs, and machine identities. Centralised, policy-driven authorization is now a governance requirement, not a design preference.
NHIMG editorial — based on content published by Cerbos: OWASP Top 10 2025 and broken access control
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every inline authorization check Map all if-role checks, object ownership checks, and parameter-based access rules across applications and services.
- 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.
- Treat machine identities as first-class authorization subjects Review service accounts, API keys, tokens, and workload identities alongside human roles.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- A closer look at policy files, expression logic, and how the decision point evaluates context before returning allow or deny
- Examples of fine-grained object-level rules for ownership, region, thresholds, and multi-tenant boundaries
- Implementation guidance for replacing inline application checks with a central policy repository and unified enforcement pattern
- Audit and compliance framing that maps authorization architecture to security reviews and pentest evidence
👉 Read Cerbos' analysis of OWASP Top 10 2025 and broken access control →
Broken access control in 2025: what IAM teams need to fix?
Explore further
12/06/2026 7:32 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Broken access control still exposes modern application authorization
