A Major Shift in Security Priorities
On September 24, 2021, OWASP released an updated Top 10 list that significantly altered the landscape of security priorities. SQL injection, which had long been a top concern, fell to third place. Taking its place was Broken Access Control, previously ranked fifth. This change highlighted a critical issue: your access control implementations are failing at scale, as evidenced by 82% of vulnerabilities found in application code.
Timeline of Changes
2017 OWASP Top 10: Broken Access Control was ranked #5, while SQL injection was at the top, reflecting a focus on database attacks.
2018-2020: The rise of cloud-native architectures, microservices, and API-first designs led to fragmented access control logic across services.
September 24, 2021: The new OWASP Top 10 placed Broken Access Control at #1, with 34 Common Weakness Enumerations (CWEs) mapped to it.
Post-2021: Breach reports confirmed attackers were exploiting authorization flaws to move laterally, escalate privileges, and access unauthorized data.
Common Failures in Access Control
The rise of Broken Access Control revealed three key failures:
Inconsistent Authorization Across Services: As microservices became common, access checks were often implemented inconsistently. Some services verified user roles properly, while others did not.
Missing Function-Level Access Control: Applications often failed to check if users could delete, modify, or export resources. This includes issues like Insecure Direct Object References (IDOR).
Lack of Continuous Verification: Many teams did not validate access control in production, missing patterns like a user accessing 10,000 records in sequence, a typical IDOR exploitation.
The presence of Vulnerable and Outdated Components at #6 on the 2021 list compounded these issues. Teams often failed to update open source authentication libraries, leaving vulnerabilities unpatched.
Standards and Requirements
OWASP ASVS v4.0.3 outlines key requirements:
- V4.1.1: Enforce access control on a trusted service layer.
- V4.1.3: Use a single, well-vetted access control mechanism.
- V4.2.1: Verify data-level access control.
PCI DSS v4.0.1: Requirement 6.4.2 mandates managing all payment page scripts loaded in the consumer's browser.
ISO/IEC 27001:2022: Control A.9.4.1 requires "information access restriction" appropriate to the risk.
SOC 2 Type II: Evaluates the effectiveness of access controls over time, with a focus on logical access controls.
Actionable Steps for Your Team
Map Authorization Decisions: Document every authorization decision in your architecture. Identify and flag any inconsistent practices.
Centralize Access Control: Use tools like Open Policy Agent or cloud-native solutions to centralize authorization logic, allowing for easier updates.
Monitor Access Control in Real-Time: Log every authorization decision with context and analyze these logs for unusual patterns.
Test Access Control in CI/CD: Ensure tests cover both allowed and denied access scenarios, verifying that unauthorized access is blocked.
Audit Open Source Dependencies: Use tools like Snyk to identify outdated authentication/authorization libraries and update them promptly.
Implement API Security Principles: Follow guidelines from the OWASP API Security Top 10 to ensure endpoint-specific access control.
Review During Threat Modeling: Explicitly address authorization during feature design to prevent unauthorized data access.
The shift to Broken Access Control as the top concern underscores the need for robust, centralized, and continuously monitored access control mechanisms. While SQL injection defenses remain important, ensuring your APIs and services enforce proper access control is crucial for security.
