1. What is broken access control?
Broken access control is a security vulnerability that occurs when an application's access control mechanism is misconfigured or bypassed, allowing users to perform actions or access resources outside their granted permissions.
In simpler terms, access control is the set of rules that determines who is allowed to do what within a system. When this mechanism breaks down, a regular user may be able to view another user's data, perform functions intended for administrators, or modify information they have no right to change.
For example, a regular customer account accesses the /admin/dashboard path and the system does not reject the request because there is no server-side permission check. This is a typical manifestation of broken access control.
Broken access control is ranked #1 by OWASP in the Top 10 web application security vulnerabilities since 2021, overtaking injection attacks. This reflects the high frequency and severe impact of this vulnerability class in practice.
2. Common types of broken access control
Broken access control is not a single vulnerability but a group of flaws with many variants. Similar to SQL injection attacks, these vulnerabilities exploit weaknesses at the application layer and can cause serious consequences if not detected early.
| Vulnerability Type | Description | Real-world Example | Severity |
| Vertical privilege escalation | Regular user performs admin-level actions | User accesses /admin/delete-user page | Critical |
| Horizontal privilege escalation | User accesses resources belonging to another user at the same permission level | User A views User B's orders by modifying the ID | High |
| IDOR | Direct reference to internal objects without access checks | ?invoice_id=1042 changed to 1043 to view another user's invoice | High |
| Missing function-level access control | Sensitive endpoints do not enforce server-side permission checks | API /api/export-data does not require an admin token | High |
| CORS misconfiguration | Server allows untrusted origins to send cross-domain requests | Attacker reads sensitive data from a spoofed domain | Medium–High |
2.1. Vertical privilege escalation
Vertical privilege escalation occurs when a user with lower permissions gains the ability to perform actions reserved for higher-privilege roles. A typical example is a customer account accessing functions such as deleting users, exporting system reports, or changing configurations that should only be available to admins. This vulnerability commonly occurs when an application only checks authentication (whether the user is logged in) but skips authorization (whether the user has permission to perform a specific action).
2.2. Horizontal privilege escalation
Horizontal privilege escalation occurs when a user accesses resources belonging to another user at the same permission level. For example, User A modifies the ID parameter in the URL from ?user_id=101 to ?user_id=102 and gains access to User B's account information, order history, or profile. This type of vulnerability is particularly dangerous in e-commerce, banking, and healthcare applications where personal data holds high value.
2.3. Insecure Direct Object Reference (IDOR)
IDOR (Insecure Direct Object Reference) is a vulnerability that occurs when an application directly uses internal identifiers such as IDs, filenames, or database keys in URLs without checking access permissions. IDOR commonly appears in APIs that are not carefully designed, particularly REST APIs using sequential numeric IDs. Users need only change the ID value to access an object belonging to someone else.
2.4. Missing function-level access control
This vulnerability occurs when sensitive functions or endpoints are not properly protected on the server side. An application may hide admin paths from the regular user interface, but an attacker can still access them directly by guessing or enumerating URLs. This flaw is often discovered through endpoint fuzzing or analysis of the application's JavaScript, where sensitive paths are sometimes exposed.
2.5. CORS misconfiguration
CORS misconfiguration occurs when a server is configured to allow requests from untrusted origins. When the CORS policy is too permissive, such as allowing all origins (*) or reflecting the request origin without validation, an attacker can create a malicious website to send requests to the target application's API and read responses containing sensitive data.
3. Business impact of broken access control
Broken access control is not purely a technical issue. When exploited, its consequences ripple across multiple layers of an organization.
3.1. Sensitive data leakage
Attackers can access and steal customer information, financial data, medical records, or confidential business intelligence. This is the most common and direct consequence of broken access control, and is particularly dangerous in industries that handle high-value personal data such as banking, insurance, and e-commerce.
3.2. Unauthorized actions
Beyond reading data, attackers can carry out destructive actions such as deleting user accounts, modifying system configurations, initiating unauthorized fund transfers, or escalating privileges to seize full control of the system. In many cases, DDoS attacks combined with broken access control allow attackers to inflict compounded damage on a business.
3.3. Compliance violations
Businesses that suffer data breaches due to broken access control risk violating critical security standards. For organizations that handle payment transactions, a PCI-DSS violation can lead to financial penalties and loss of certification. For businesses operating in markets with personal data protection regulations such as PDPA or GDPR, fines can reach millions of USD. In Vietnam, Decree 13/2023/ND-CP on personal data protection also imposes strict requirements on access control.
3.4. Long-term brand reputation damage
A serious security incident caused by broken access control is typically widely publicized, especially when user data is involved. Customer trust, once lost, is very difficult to rebuild, leading to revenue decline and significant crisis communication costs.
4. How to detect broken access control in applications
Detecting broken access control early requires a combination of different testing methods. Regular website security testing is the first step businesses should take to proactively identify vulnerabilities before they are exploited.
4.1. Manual testing
Manual testing is the most effective method for detecting broken access control because this vulnerability is heavily dependent on business logic. Testers need to create multiple accounts with different permission levels, then attempt cross-account resource and function access between those accounts.
4.2. DAST tools and penetration testing
DAST (Dynamic Application Security Testing) tools automatically send test requests to a running application to detect common vulnerabilities. Penetration testing goes deeper, simulating how a real attacker would exploit the system. Businesses should learn more about how to find website security vulnerabilities and conduct penetration tests at least once a year or after each major change to the application architecture.
4.3. Code review and permission configuration review
Code reviews focused on authorization logic help detect vulnerabilities at the development stage. Key areas to examine include: whether each endpoint enforces server-side permission checks, whether object IDs are validated against the current user, and whether CORS configuration restricts trusted origins. Integrating SAST (Static Application Security Testing) into the CI/CD pipeline enables automatic detection of insecure code patterns.
5. Effective strategies to prevent broken access control
Preventing broken access control requires building a correct authorization mechanism from the design stage, not patching it in afterward.
5.1. Principle of least privilege
Each user, process, or service should be granted only the permissions necessary to perform their specific task, nothing more. The least privilege principle limits the blast radius when an account is compromised. In practice, this means avoiding default admin grants, separating permissions by specific roles, and regularly reviewing permission lists to remove any that are no longer needed.
5.2. Deny by default
All resources and functions must deny access by default. Access is only granted when an explicit rule permits it, not the other way around. This mechanism ensures that new endpoints added to the system are not accidentally left open before their permissions are properly configured.
5.3. Server-side authorization checks, not client-dependent
All authorization checks must be performed server-side. They must never rely on client-side validation or the mere act of hiding a URL in the interface. Attackers can easily bypass any client-side check by directly manipulating requests. The server must validate each request independently, confirming whether the current user has permission to access the specific object being requested.
5.4. Logging and monitoring for abnormal access
The logging and security monitoring system must record all denied access attempts, especially unusual patterns such as: an account repeatedly attempting to access different IDs within a short time, or requests to sensitive endpoints outside normal working hours. Automated alerts when such patterns are detected help the security team respond before damage occurs.
6. How VNIS helps mitigate broken access control risks
VNIS by VNETWORK is designed to protect Web/App/API from external threats, it cannot replace directly patching broken access control vulnerabilities in code. This is a business logic vulnerability embedded deep within the application layer. A WAF cannot determine whether User A is permitted to view User B's data. For internal code, businesses must still proactively audit and fix the flaw themselves.
However, the AI WAF platform within VNIS serves as a valuable supplementary defense layer, helping mitigate risk at points where code has not yet been patched:
- Rate limiting and IDOR brute-force detection: when an account repeatedly changes ID parameters within a short time, VNIS identifies the abnormal pattern and automatically triggers a blocking or challenge mechanism.
- Protection for known sensitive endpoints: admin paths or internal APIs can be configured with dedicated rules in VNIS to restrict access from untrusted sources.
- Comprehensive traffic logging and monitoring: VNIS records all requests with full detail, helping the security team detect privilege escalation behavior after an event and conduct forensic investigations.
VNIS works most effectively when combined with secure coding practices, not as a replacement for them. If broken access control is a wall that must be built correctly from the inside out, then VNIS is the outer perimeter that buys time and limits damage while the inner wall is still being completed.
7. Conclusion
Broken access control is the most critical vulnerability in the OWASP Top 10, yet it is also entirely preventable if organizations build the correct authorization mechanism from the start. The principles of least privilege, deny by default, and server-side authorization checks are indispensable foundations.
FAQ - Frequently asked questions about broken access control
1. How is broken access control different from an authentication vulnerability?
Authentication verifies a user's identity, confirming who you are. Broken access control occurs after authentication and governs what you are allowed to do. A system can have strong authentication such as two-factor authentication and password hashing, yet still have broken access control if, once logged in, users can access resources outside their permitted scope.
2. Where does OWASP rank broken access control?
According to the OWASP Top 10 2021 edition, broken access control is ranked number 1 (A01:2021), up from position number 5 in the 2017 edition. This rise reflects the high frequency with which it appears in real-world applications and the severity of damage when exploited.
3. Can small applications or startups be affected by broken access control?
Yes. Broken access control does not discriminate by application size. Smaller applications are often at higher risk because they typically lack dedicated security review processes and development teams with limited security expertise. Many popular web frameworks do not handle authorization automatically, placing the burden on developers to implement it correctly.
4. Can a WAF fully prevent broken access control?
A WAF is an important supplementary defense layer but cannot fully replace fixing the vulnerability at the code level. A WAF, especially a next-generation AI WAF, can detect and block known attack patterns, but broken access control vulnerabilities rooted in complex business logic sometimes require direct patching in code. The best strategy is to combine both: secure coding and a WAF such as VNIS.
5. How often should broken access control testing be performed?
Broken access control testing should be integrated into the regular development process through code reviews and SAST within the CI/CD pipeline. In addition, in-depth website security assessments should be conducted at least once a year and are mandatory after every major architectural change, new feature addition, or modification to the permission structure.