Application Security | Data Security | OWASP | Vulnerability

Broken Access Control

Welcome to Secumantra! We have already covered top four vulnerabilities from OWASP Top Ten 2017 edition – injectionbroken authentication , sensitive data exposure and XML external entities. In this post, we’re going to talk about the number five vulnerability – Broken Access Control. Broken Access Control covers all access control issues that can make your website vulnerable.

OWASP (Open Web Application Security Project) is a nonprofit foundation that works to improve the security of software. OWASP Foundation is globally recognized by developers as the first step towards more secure coding. It releases OWASP Top Ten list every 2-3 years sharing the most critical security risks to modern web applications.

What is Access Control?

Access control is how web applications control what content and features should be accessible to different users. Sometimes it is called authorization.

It governs what ‘authorized’ users are allowed to do. A web application’s access control model is closely tied to the content and functions that the site provides. In addition, the users may fall into a number of groups or roles with different abilities or privileges. Access control sounds like a simple problem but is significantly difficult to implement correctly.

Broken Authentication vs Broken Access Control

Let us first understand the difference between authentication and authorization in short.

Now consider that you are doing penetration testing for a website. Assume, you found an exposed administration dashboard without authentication. This is an authentication issue.

Now the developer fixes the authentication vulnerability, you log in as a normal user and find that you still have access to the dashboard. In this case, the developer forgot to validate if the user is authorized to access the admin dashboard. This is an authorization issue.

So broken access control vulnerability happens when the application fails to properly validate authorization after the user has been authenticated.

Real World Challenges

Developers frequently underestimate the difficulty of implementing a reliable access control mechanism. Many of these schemes were not deliberately designed, but have simply evolved along with the web site. In these cases, access control rules are inserted in various locations all over the code. As the site nears deployment, the ad-hoc collection of rules becomes so unwieldy that it is almost impossible to understand.

Many of these flawed access control schemes are not difficult to discover and exploit. Frequently, all that is required is to craft a request for functions or content that should not be granted. Once a flaw is discovered, the consequences of a flawed access control scheme can be devastating. In addition to viewing unauthorized content, an attacker might be able to change or delete content, perform unauthorized functions, or even take over site administration.

One specific type of access control problem is administrative interfaces that allow site administrators to manage a site over the Internet. Such features are frequently used to allow site administrators to efficiently manage users, data, and content on their site. In many instances, sites support a variety of administrative roles to allow finer granularity of site administration. Due to their power, these interfaces are frequently prime targets for attack by both outsiders and insiders.

How to Discover Broken Access Control?
  • Browse the website while logged in and log all pages visited. Log out and revisit all pages. If content that should only be available to logged-in users is shown on these pages, the website is vulnerable.
  • Simply bruteforce different paths for website URL. An example would be /admin, /settings or similar that only an admin should be allowed to visit. If any user can access those, this would be considered a vulnerability. This is also called forced browsing, – in simplified terms, enumerating and accessing resources that are not referenced by the application, but can still be accessed.
  • Identify user IDs and similar data in requests and simply change them to something else. Chances are that you can receive information about another user or even execute actions in their name. This would be similar to the Twitter vulnerability mentioned above in Well-known events.

Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.

  • With the exception of public resources, deny access to features by default.
  • Use Access control lists and role-based authentication mechanisms. Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
  • Penetration Testing

The most important step is to think through an application’s access control requirements and capture it in a web application security policy. OWASP strongly recommends the use of an access control matrix to define the access control rules.

Without documenting the security policy, there is no definition of what it means to be secure for that site. The policy should clearly documented what types of users can access the system, and what functions and content each of these types of users should be allowed to access.

Also, the design documentation should capture an approach for enforcing this policy. The code that implements the access control policy should be well structured, modular, and most likely centralized. A detailed code review should be performed to validate the correctness of the access control implementation.

Developers and QA staff should include functional access control unit and integration tests.

The access control mechanism should be extensively tested to be sure that there is no way to bypass it. This testing requires a variety of accounts and extensive attempts to access unauthorized content or functions. In addition, penetration testing can be quite useful in determining if there are problems in the access control scheme.

Carefully review each interface to make sure that only authorized administrators are allowed access to administrative functions. The primary recommendation is to never allow administrator access through the front door of your site if at all possible.

Also, if there are different types or groupings of data that can be accessed through the interface, make sure that only authorized data can be accessed as well. If such interfaces employ external commands, review the use of such commands to make sure they are not subject to any of the command injection flaws.

OWASP Risk Rating

Let us analyze OWASP risk rating matrix –

Exploitability – Detecting and taking advantage of this vulnerability is easy. Often, all it takes is for the attacker to attempt a specific action that should require authentication. If the request succeeds, the page is considered vulnerable. What is hard to do here is to figure out every page that is at risk and know exactly which features could potentially lead to something dangerous.

A5:2017-Broken Access Control (Source – OWASP)

Prevalence – Broken Access Control is often a problem that emerges in applications that have gradually grown in size. Instead of deliberately designing schemes regulating access from the beginning, developers have added them over time.

In cases where access control is not centralized, this often results in a very complex scheme that is hard to fully understand. A complex scheme, in turn, leads to mistakes and vulnerabilities.

Impact – The potential impact of Broken Access Control greatly depends on what kind of information or features the attacker can gain access to. This can be anything from seemingly useless information to a full system takeover.


Access control is the system which controls access to the information or application features based on different user roles like a guest, normal user or an admin. Access control enforces policy such that users cannot act outside of their intended permissions.

Improperly configured or missing restrictions on authenticated users allow them to access unauthorized functionality or data, such as accessing other users’ accounts, viewing sensitive documents, and modifying data and access rights. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user.

Web applications need to implement role based access control (RBAC) depending on how critical information being handled. Penetration testing can also be helpful to find out broken access control vulnerabilities.

When securing your applications against this type of vulnerability, it is always a good practice to follow defense in depth strategy.

Thank you for reading. Stay Safe, Stay Secure!

Similar Posts