Broken access control still tops the list: OWASP top 10 2025

The eighth edition of the OWASP Top 10 has landed, and once again, the top spot goes to A01: Broken Access Control. This isn’t just a repeat headline, it underlines a persistent gap in application security programmes. At Cerbos, our mission is to ensure teams don’t reinvent access-control logic, which means helping you establish policy-driven, fine-grained authorization that actually scales and withstands audits.

Why broken access control continues to dominate

In the introduction to the 2025 list, OWASP states that “Brok­en Access Control maintains its position at #1 as the most serious application security risk … on average 3.73% of applications tested had one or more of the 40 CWEs in this category.”

What does that tell us?

1. The fundamentals of authorization and access control are still fragile across many applications.

2. Legacy patterns, such as ad-hoc role checks, simple role-based locks,and tangled if-else logic, don’t hold up.

3. As architectures become more complex, such as microservices, multitenancy, APIs, and machine identities, the access control surface grows, but often the governance doesn’t. In short: this isn’t just a “we need better controls” message, it’s “we need a structured, scalable, and policy-centric approach to access control”.

Why Cerbos is uniquely positioned to help

If you’ve read our OWASP top 10 2021 write-up, you know we’ve been saying this for years. With the 2025 list reaffirming it, the time to act is now. Here’s how Cerbos addresses the challenge:

1. Decoupling authorization from application logic

Instead of embedding access checks all over your codebase (if user.role == “admin”, else …), Cerbos lets you externalize access logic into policy files. That means you get:

• Centralized policy management.
• Consistent enforcement across services and interfaces.
• Audit-friendly trail of who can do what and under what conditions.

2. Fine-grained resource (object)-level control

One of the big weaknesses OWASP calls out relates to object-level access (“Broken Object Level Authorization”), where a user accesses or manipulates an object they should not. With Cerbos, you can express policies such as:

apiVersion: "api.cerbos.dev/v1"
resourcePolicy:
  resource: document
  version: "default"
  rules:
    - actions:
        - read
        - update
        - delete
      effect: EFFECT_ALLOW
      roles:
        - manager
      condition:
        match:
          expr: |
            R.attr.owner == P.id
            && P.attr.region == R.attr.region

This kind of policy logic ensures users act only on the resources they truly should have access to, minimising the “force-browse”, “ID-tampering”, or “object parameter manipulation” attacks that make access control vulnerabilities.

3. Context-aware, attribute-based access control

The old “role only” check is no longer sufficient. Modern apps require context: time of day, location, ownership, financial threshold, 2FA status, and multi-tenant boundaries. Cerbos supports ABAC implicitly: you can incorporate attributes of user, resource, action, and environment into your CEL (Common Expression Language) conditions. For example:

P.attr.is2faVerified == true && P.attr.region == R.attr.region && R.attr.value < P.attr..maxApprovalAmount

Because your policies are both expressive and maintainable, you align with the principle of least privilege, enforce deny-by-default, and reduce drift.

4. Scalability, auditability, and central governance

As your organization grows (multiple microservices, many teams, tenants, roles, domains), ad-hoc code checks quickly become unmanageable. Cerbos gives you:

• A single policy repository or policy store where teams govern access rules.
• Versioned policies, policy-trial capability, and audit logs.
• A standard invocation pattern (send user, action, resource, context → ask PDP → allow/deny) which simplifies integration and testing. This is precisely the kind of governance that OWASP says is needed to bring down the prevalence of access control faults.

How to get started with Cerbos in light of OWASP 2025

Here’s a recommended roadmap:

1. Audit existing access patterns

   • Identify places you rely on inline “if-role” logic, parameterised object access checks, and resource ownership checks scattered across services.
   • Map out where bypasses, force-browse, or insecure direct object references (IDORs) are possible.

2. Define your policy model

   • Identify entity types (users, roles, tenants, resources) and attributes you’ll need (region, department, ownership, thresholds, 2FA flags).
   • Decide on resource URN naming (e.g., tenant:{tenantId}:project:{projectId}:service:{serviceId}) and action categories.

3. Write expressive policies

   • Begin with coarse‐grained policies (e.g., can user in role admin do action X on resource Y?).
   • Then drill into fine-grained rules (ownership, region matching, thresholds, time-bound permissions).
   • Use CEL to capture contextual checks.

4. Integrate and enforce

   • Replace scattered access logic with a unified Cerbos PDP call.
   • Ensure that every entry point (UI, API, worker service) uses the same enforcement layer.
   • Deny-by-default will always be the default state.

5. Govern, monitor, and iterate

   • Version your policies, include tests, and elevate review.
   • Monitor which policy decisions are made (which resources get denied, which attributes triggered decisions).
   • Use policy simulation or sandboxing for new rules.

6. Align with audit/compliance

   • Because Broken Access Control remains at the top of OWASP’s risk list, emphasize your policy architecture in security reviews, pentests, and compliance documentation.
   • Demonstrate that you have a central policy-based system, not disparate role checks in code.

Final word

The fact that Broken Access Control has retained the #1 spot in OWASP Top 10 2025 means that despite knowing what the problem is, many organizations still struggle to deploy authorization in a robust, centralised, context-aware way.

At Cerbos, we believe that the right answer to this persistent problem is policy-driven, fine-grained, expressive access control, detached from business logic and owned by governance teams.

If you’re facing a pentest, preparing for an audit, or simply attempting to scale your authorization controls across a growing architecture, now is the time to act.

If you want to dive deeper into implementing and managing authorization, check out Cerbos, or speak with a Cerbos engineer.