OWASP Top 10 - Broken Access Control

Anyone concerned with IT security cannot ignore the OWASP Top 10. The non-profit organization Open Web Application Security Project (OWASP) publishes the 10 most critical security risks for web applications in this list, which was last updated in 2021. At number 1 on this list is Broken Access Control, which we cover in theory and practice in this article. After clarifying the basics, we'll show you 3 Broken Access Control attacks in the OWASP Juiceshop. Finally, we explain how you can protect your web application against such attacks.

Table of contents

Basics: OWASP Top 10 and Broken Access Control

What is OWASP?

The Open Web Application Security Project, or OWASP for short, is an international non-profit organization dedicated to the security of web applications. OWASP's work includes several free projects that address everything from development and testing to the secure operation of web applications. Probably their best known project: The OWASP Top 10.

The OWASP Top 10

OWASP periodically publishes an updated list of the ten most critical security risks for web applications. The last update was in 2021.

OWASP itself describes the Top 10 as an "awareness document" and only as the minimum in terms of security, which should go hand in hand with web applications. For a first introduction to the topic of security in web applications, however, the TOP 10 are just right. However, if you want to delve deeper into the topic, you should refer to the OWASP Web Security Testing Guide (WSTG) or OWASP Application Security Verification Standard (ASVS) projects, depending on the use case, as these cover the topics in greater depth.

At the top of the OWASP Top 10 is Broken Access Control, which we address theoretically and practically in this post.

How secure is your web application?
Are you prepared against all OWASP top 10 security risks?
To the Web Application Penetration Test

A01:2021 - Broken Access Control

Before we get into the topic of Broken Access Control, we first need to clarify what Access Control means with regard to web applications:

An access control describes the rights and restrictions of an object to a resource or an action.

For example, a user should only be allowed to access his own accounts with his online banking account and make bookings there accordingly. However, access to another user's account should not be allowed.

We divide access control into the following categories:

  • Horizontal access control: Horizontal access controls are mechanisms that restrict user access to resources for which the users are authorized. This includes the online banking scenario just described.
  • Vertical Access Control: Vertical access controls are used to limit access to important functions that should not be available to other types of users. This means that different types of users have access to different application functions. For example, an administrator can modify or delete the account of any user, while a normal user has no access to these actions.
  • Contextual access control: Contextual access controls restrict access to functions and resources based on a state or the user's interaction with the application. For example, contextual access control prevents a user from performing actions in the wrong order and changing the contents of their shopping cart on a shopping website after they have already purchased the item.

In terms of access control, however, we also need to consider authentication and session management, as these are the starting points for access control.

  1. Through authentication, the user logs in to be authorized.
  2. Session management ensures that subsequent HTTP requests also originate from the same user, since the Internet protocol HTTP operates statelessly. This means that as soon as a request from a client is processed by the web server, the connection is terminated again. However, since a user does not want to re-enter his or her credentials on every newly accessed page, the information must be stored, transported and verified in some way.

Now that we know what an access control is, we can understand what is meant by a broken access control:

A Broken Access Control is when a user is able to bypass vertical, horizontal, or contextual access controls. Put simply, users gain access to sensitive data or are allowed to perform tasks for which they should not be authorized.

Field Test OWASP Top 10: Broken Access Control Attacks

What does the OWASP Juice Shop have to do with the OWASP Top 10?

OWASP Juice Shop is a web application with a lot of security vulnerabilities. The application is intended to allow anyone to exploit the OWASP Top 10 once themselves without incurring any penalties.

For a better understanding, let's take a look at three Broken Access Control attacks based on the OWASP Juice Shop below.

  1. Attack: Post some feedback in another user's name. (Eng. Attack: Post some feedback in another user's name.)
  2. Attack: View another user's shopping basket. (Eng. Attack: View another user's shopping basket).
  3. Attack: Put an additional product into another user's shopping basket. (Eng. Attack: Put an additional product into another user's shopping basket).

The OWASP Juice Shop can be installed on Windows, MacOS or Linux or used as a container. The documentation of the Juice Shop is in English, but nevertheless very well described:

Installation OWASP Juice Shop

Warning: OWASP Juice Shop is an application with a lot of vulnerabilities that can be easily exploited. Therefore, you should install it on a test device that is accessible only to yourself.

In our case, we chose the Docker container because Docker itself is easy to install and the OWASP Juice Shop container is quick to download and launch.

When starting the Docker container, it is important to note that the variable


is passed along so that all Broken Access Control attacks (challenges) can also be tried. This can be done via the Docker Desktop interface:

Docker Desktop interface

or you start the container via the shell:

					docker run --name juice-shop -e "NODE_ENV=unsafe" -p 3000:3000 bkimminich/juice-shop

Any browser can be used to exploit the vulnerabilities (difficulty level: High). However, we recommend the use of a proxy server. You can read more about this in our Proxy Basics article.

In the rest of the article we will use Burp Suite Community Edition.

3 Broken Access Control Attacks in the OWASP Juice Shop

Have you started the OWASP Juice Shop?

The Burp Suite Community Edition open?

If you answered yes to both questions, we're ready to go.

In Burp Suite Community Edition, if not already preselected, we select the Proxy tab.

Burp Suite Community Edition "Proxy" Tab

After that we open the browser via Open Browser ...

Burp Suite Open Browser

...and go to the website:


Since we have Docker installed locally, we can reach our Juice Shop at the address

Owasp Juice Shop

If everything is set up correctly, we will now see the OWASP Juice Shop home page and can begin the first challenge.

Note: The following attacks including the solutions can also be found in the OWASP Juice Shop documentation:

Attack 1: Post some feedback in another user's name.

Possibility 1

In the first step, we click on the Burger menu in the upper left corner and select About Us.

OWASP Top 10
OWASP Juice Shop

On this page, the slider shows the existing and already submitted feedbacks.

OWASP Juice Shop

Now we go to the Customer Feedback page via the Burger menu.

OWASP Juice Shop

Here we can give feedback ourselves once for the test, which we can view on the About Us page afterwards.

OWASP Juice Shop
OWASP Top 10

Now, to manipulate the Author field or the UserID, we intercept the POST request to the web server (interception) and modify it.

To do this, we first look at the POST request made in Burp Suite under the HTTP history tab.

Burp Suite under the "HTTP history" tab

And then the response of the web server.

You will notice that there is a UserID field with the value zero.

Response of the web server

This gives us a hint that the server requires a UserID when submitting feedback. In turn, we can try to manipulate this field in the subsequent POST request. To do this, we start intercepting the web requests in Burp Suite in the Intercept tab by clicking on Intercept is off.

Burp Suite in the "Intercept" tab

If the button is set to Intercept is on, we provide feedback again.

If the button is set to "Intercept is on", we provide feedback again.
If the button is set to "Intercept is on", we provide feedback again.

We notice that this time we did not receive a pop-up window confirming the submission of the feedback. This is because we stopped the web requests through our proxy to manipulate them.

To do this, we go back to the Burp Suite and click the Forward button in the Intercept tab until we see the POST request of our feedback.

Burp Suite Rider "Intercept

We now manipulate this by adding a value to the UserID parameter and clicking the Forward button. After that we can turn off the interception again and view our manipulated POST request in the HTTP history tab.

Parameter "UserID" Button "Forward

Here we see that the server has successfully accepted our POST with the changed UserID. This means that we no longer submitted the feedback with UserID null (anonymous), but as a user with UserID 2. A successful Broken Access Control.

A successful Broken Access Control.
Possibility 2

Another way to solve this challenge is to display the hidden UserID field on the Customer Feedback web page.

"UserID" field on the "Customer Feedback" web page.

To display the hidden field, we open the Developer Tools via Right Click - Inspect.

"Right click - Examine" the "Developer Tools".
OWASP Juice Shop

In the Elements tab we search for the word hidden using the standard keyboard combination CTRL+F.

In the "Elements" tab we search for the word "hidden" using the standard keyboard combination CTRL+F.

We are looking for the line:

					   <input _ngcontent-reo-c122="" hidden="" type="text" id="userId" class="ng-untouched ng-pristine ng-valid">

When we find the line, we see the field id="userId" of type="text". This is hidden, that is hidden.

We remove the "hidden

We remove the hidden and already we see the UserID field on the web page, where we can enter any ID we want: A Broken Access Control.

Broken Access Control
Broken Access Control

Attack 2: View another user's shopping basket.

Possibility 1

For this attack we need to log in as a user. To do this, we click Account in the upper right corner and select Login.

OWASP Juice Shop
OWASP Juice Shop Login

After that we log in as user jim.

E-mail address: jim@juice-sh.op

Password: (doesn't matter, just must not be empty)

The peculiarity of the login is that we do not know the password of jim. Therefore, we have to perform the login via an SQL injection. This is done by adding '-- to the end of the email address.

Explanation: The apostrophe ' terminates the string of the e-mail field in the SQL query and the two dashes -- indicate that everything following the two dashes is a comment. That is, the password is commented out in the query.

A blog post on SQL injection will follow.

OWASP Juice Shop Login
OWASP Juice Shop Shopping Cart "Your Basket

After successful registration we call our shopping cart Your Basket.

OWASP Juice Shop Shopping Cart "Your Basket

Then we search our HTTP history in Burp Suite for the shopping cart call. In the request, we notice that the URL includes the UserID (in the case of jim = UserID 2).

"HTTP history" in Burp Suite

Let's change these for a change.

To do this, we start the interception in Burp Suite and call the Your Basket shopping cart again.

OWASP Juice Shop Shopping Cart "Your Basket

In the GET request from the shopping cart call, we can manipulate the parameters or fields, as in the first attack.

OWASP Juice Shop Shopping Cart "Your Basket

We change the 2 in the URL to a 1 (the admin's UserID) and click Forward. Then we stop the interception and look at the result in the browser.

OWASP Juice Shop Shopping Cart "Your Basket

Our shopping cart is now different. And again there is a Broken Access Control .

Broken Access Control

But we can also have a look at the result in our HTTP history. There we can also see the response to our manipulated GET request.

HTTP history
Possibility 2

As in the first attack, there is a second possible solution in this challenge.

To do this, we open the developer tools again and this time look at our session storage in the Application tab.

Developer Tools Tab Application Session Storage

There we find the parameter bid, which possibly stands for BasketID, with the value 2. Since our user ID is 2, the most obvious thing is that the value 2 in bid is also related to the UserID.

We change the value 2 to 1 and reload the shopping cart web page.

Change once the value 2 to 1

And also this time we don't see jim's shopping cart anymore, but the admin's one. This means that there is a Broken Access Control on this path as well.

Broken Access Control

Attack 3: Put an additional product into another user's shopping basket.

Our last challenge.

However, the procedure at the beginning is the same. We execute the action we want to test or manipulate once.

Fruit Press

That is, we put a product in our shopping cart. We have chosen the Fruit Press.

Fruit Press

Then we look at the process in the HTTP history. In the POST request we notice that a BasketID is passed.

POST Request "BasketID is passed

We try to manipulate these again. So we change the parameters and fields while we stop the web call with the interception process, manipulate it and forward it again. We notice that changing the BasketID does not lead us to the goal here.

So we have to manipulate our POST request differently in this case. Instead of a parameter change we add a parameter this time (HPP = HTTP parameter pollution).

Important: In this Juice Shop scenario, note that the added item is not already in the shopping cart of the logged-in user. In the attack shown here, we deleted the Fruit Press from jim's shopping cart before the interception.

"Fruit Press" deleted from jim's cart before interception
"Fruit Press" deleted from jim's cart before interception

After we pass the POST to the web server, we can see a successful Broken Access Control in the server's response in the HTTP history tab.

Broken Access Control

Since we now know how to view the admin's shopping cart, we can also control our successful attack in the browser: The product Fruit Press is added to the admin's shopping cart.

The product "Fruit Press" has been added to the admin cart.

OWASP Top 10 Solution: How to protect your web application from Broken Access Control Attacks

Unfortunately, there is no one right solution for Broken Access Control, as every web application or access control differs in its implementation. However, there are some points that can be considered:

  1. The implementation of access controls throughout the web application.
  2. An elaborated and documented role, rights and auditing concept
  3. A clean logging of errors
  4. Session cookies should be invalidated after logging off the server
  5. Stateless JWT tokens should be rather short-lived
  6. Following the OAuth standards
  7. An awareness of the developers
  8. The implementation and configuration of a Web Application Firewall (WAF)

Recommendation: Because web applications are different and change over time, we recommend performing regular audits and web application penetration tests to identify flawed broken access control vulnerabilities.

Need help hardening your web app?
We will find all the security holes for you and guide you through their closure.
To the Web Application Penetration Test

Table of contents

Do you want to be part of our team?