## Why broken access control continues to dominate In the introduction to the 2025 list, OWASP [states](https://owasp.org/Top10/2025/0x00_2025-Introduction/) that “Broken 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](https://www.cerbos.dev/blog/broken-access-control-is-the-1-issue-in-owasp-2021-top-10) 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](https://www.cerbos.dev/blog/externalized-authorization-management-eam-and-benefits) 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](https://www.cerbos.dev/blog/how-to-implement-resource-based-authorization) (“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](https://www.cerbos.dev/blog/enterprise-access-control) 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](https://www.cerbos.dev/features-benefits-and-use-cases/centralized-management) policy repository or policy store where teams govern access rules. * Versioned policies, policy-trial capability, and [audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/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**](https://www.cerbos.dev/product-cerbos-hub), or speak with a [**Cerbos engineer**](https://www.cerbos.dev/workshop).* ## FAQ ### What is the OWASP Top 10 2025? The OWASP Top 10 2025 is the latest edition of OWASP’s widely adopted list of the most critical security risks in web applications. It highlights persistent vulnerabilities such as Broken Access Control, insecure design, and injection flaws. The list serves as a baseline for modern application security programs. ### Why is Broken Access Control still #1 in OWASP 2025? Broken access control remains the top issue because many organizations rely on ad-hoc role checks, scattered logic, and inconsistent governance across services. As architectures grow more complex, these gaps lead to object-level, parameter-level, and context-based authorization failures. Centralized, policy-driven authorization is needed to reduce these risks. ### How can teams prevent Broken Access Control in 2025-era architectures? Teams should externalize authorization, define policies centrally, and enforce deny-by-default. Use fine-grained, expressive rules that incorporate attributes of users, resources, and context. This reduces drift, improves auditability, and ensures consistent decisions across services and UIs. ### How does contextual or attribute-based access control help meet OWASP recommendations? Contextual checks, such as region, ownership, thresholds, or 2FA status, let systems enforce least privilege dynamically. Attribute-based rules (ABAC) address real-world security conditions that simple role checks can’t capture, aligning with modern OWASP guidance. ### How does Cerbos help address OWASP Top 10 2025 risks? Cerbos provides centralized, policy-driven authorization designed for multi-service, multi-tenant architectures. It enforces fine-grained resource controls, supports ABAC, and offers audit logs, versioned policies, and a clean separation from application logic - directly addressing issues highlighted by OWASP. ### What should security teams do after reviewing OWASP Top 10 2025? Teams should audit their current access patterns, identify inline role logic and object-level gaps, map required user and resource attributes, and adopt scalable authorization patterns. This ensures long-term resilience rather than short-term patching.