According to the OWASP Top 10, Broken Access Control is the #1 security vulnerability facing developers today. This is up from #5 in 2020, which means it’s a major problem — and it’s spreading.

APIs are often the source of these security risks. According to the OWASP Top 10, hackers often bypass access controls using attack tools that modify access requests. APIs themselves can sometimes give cybercriminals unauthorized access via APIs missing access controls for POST, PUT and DELETE, as well. CORS misconfiguration can allow for unauthorized API access from unauthorized or untrusted sources, as one final security risk.

APIs are also susceptible to numerous different forms of broken access control. Broken authentication, broken function-level authorization, and broken object-level authorization are all examples of different kinds of broken access control.

It’s imperative that we do everything in our power to ensure our APIs are secure. Even one instance of unauthorized API access can expose millions of sensitive user data records. Understanding broken access control is the first step in preventing API hacks. Let’s start by looking at broken access control to build a better understanding. Then we’ll consider some best practices to help you make sure your APIs are secure.

What Is Broken Access Control?

At its essence, broken access control is fairly simple. It’s any situation that allows attackers to access, modify, delete or perform actions outside of an application’s intended function. When access control is broken, attackers are sometimes able to access functions outside of their permissions.

Many common cyberattacks fall under the umbrella of broken access control. A simple example would be a user modifying an endpoint URL to gain admin privileges.

A Practical Example of Broken Access Control

Let’s take a more in-depth look at a real-world scenario to help you better understand the risks posed by broken access control. Imagine a financial API that assigns each user a unique ID. When the user requests their account information, it’s returned to an endpoint with that User ID.

Now imagine there’s no other user authorization process in place. Someone could simply modify the user ID endpoint number and gain access to anyone‘s account information. This is known as an Insecure Direct Object Reference (IDOR), and it’s just one of many different kinds of potential broken access control attacks.

Let’s consider an actual broken access control case to take things beyond the hypothetical. In August 2015, a security researcher named Laxman Muthiyah discovered a security vulnerability in Facebook that allowed a user to become an admin of any Facebook Page using an API request.

This API security risk looked like this:

POST /<page_id>/userpermissions HTTP/1.1

Host :  graph.facebook.com

Content-Length: 245

role=MANAGER&user=<target_user_id>&business=<associated_business_id>&access_token=<application_access_token>

In this example, anyone could modify the API endpoint to change any user’s privileges. This is a major oversight that could have had severe consequences.

Types of Broken Access Controls

Broken access controls can be divided into three main categories: horizontal, vertical, and context-dependent.

Let’s take a quick look at each.

Horizontal Broken Access Controls

Horizontal broken access control is when a user can access resources from other user accounts with the same privilege level. The example we gave earlier of modifying a User ID endpoint to retrieve another user’s account info would be an example of horizontal broken access control.

Both broken object-level authorization and broken authorization, in general, are other examples of horizontal broken access control that affect APIs.

Vertical Broken Access Control

Vertical broken access control is when someone accesses privileges they don’t normally possess. The Facebook API vulnerability mentioned previously, where a user can change any user to the admin of a Facebook Page, is an example of vertical broken access control.

Broken function-level access is another example of vertical broken access controls as they manifest in APIs.

Context-Dependant Broken Access Control

Context-dependent broken access control is when a user can perform functions out of order. A user being able to remove an item from their shopping cart after it’s already been purchased is an example of context-dependent broken access control.

Examples of Broken Access Control API Vulnerabilities

When not secured or implemented properly, APIs can be particularly vulnerable to broken access control. This can have potentially disastrous consequences, as seen via the recent Optus data breach.

The trouble started when Optus developers created an API exposing sensitive user data without requiring any form of authorization, including a username or password. Therefore, their first mistake was making a public API with zero security — anyone who found that API could have gained access to all manner of sensitive data.

Secondly, a public API should never connect directly to sensitive user data. This oversight caused the Optus data breach to leak:

• Driver’s License numbers
• Phone numbers
• Dates of birth
• Home addresses

Some security analysts think this data could’ve been exposed on the internet for up to 3 months.

Finally, the last error that made this such a dramatic data breach was developers using incremental account numbers for User IDs. This gave hackers access to additional account info simply by counting upwards. This is a prime example of horizontal broken access control and the risks it presents.

How To Prevent Broken Access Control

Now that we understand broken access control, let’s consider some ways you can prevent it to ensure your APIs are secure.

Continuous Inspection and Testing Access Control

Continuous inspection and assessment of access control are one of the most effective ways to prevent broken access control. This can detect new security vulnerabilities and correct them as quickly as possible.

Continuous inspection and testing of APIs is its own art form. An example of some things you can test for in your APIs include:

• Response data-structure
• Presence of specific parameters in the response
• Absence of specific parameters in the response
• Response time
• Response headers
• Cookies
• Response time

Any anomalies could indicate an API vulnerability that might need to be addressed. Knowing what to look for is essential to writing API tests.

Deny Access By Default

Restricting access to all resources or functionality unless they’re intended to be public by default is one of the most surefire ways to prevent broken access control. Enabling Just-In-Time (JIT) access removes many of the risks that come with standing privileges, as well. Deny by default states help support a zero-trust architecture, which is an increasingly popular and recommended security approach.

Limit CORS Usage

Cross-Origin Resource Sharing (CORS) is another common source of broken access control. CORS relies on proper HTTP headers between the client and the user. When CORS isn’t set up properly, hackers can use a domain to send unauthorized requests to your API.

Set Up Role-Based Access Control (RBAC)

Enabling roles is another of the most dependable ways to ensure proper access control. Rather than relying on unique IDs, users are assigned to roles that dictate their permissions. The standard Admin and User roles are easy examples of why roles are effective in ensuring proper access control. An authorization layer utilizing roles can verify that a user is authorized to access a particular resource or functionality.

Enable Mandatory Access Control

Certain resources can be restricted if they contain sensitive information. Only privileged users, such as Admins, can access restricted resources. Mandatory access control is a popular format used by government and military organizations, to give you some idea of its efficacy. It’s a good idea to implement across all levels of your organization.

Verify User Ownership

Your API should verify that a user owns a resource rather than assuming a user can create, read, update, or delete a resource. Unique IDs or roles are both useful for verifying user ownership of a resource. API tokens or cookies prevent unauthorized editing of resources, as well. Single Sign-On services are useful for allowing widespread access to multiple resources without having to provide authorization each time.

Enable Rate Limiting

Rate limiting your APIs is another valuable strategy to prevent unauthorized API access. It’s also effective against automated API attacks.

Rate limiting is always a good strategy for API security. Remember, to properly implement rate limiting, it’s important to monitor your API across time. Not all unauthorized API access happens at one time. Having historic data lets you notice unusual patterns that occur across a span of time.

Use An API Gateway

Proper API access is becoming a popular topic among cybersecurity and IT professionals. Many of the popular API gateways have built-in features for access control. Google Cloud, for example, uses Identity and Access Management (IAM) to make sure of proper usage of your API, for instance.

Amazon AWS has a number of native features for controlling and managing your APIs, as well. These include:

• Resource policies
• IAM roles and policies
• IAM tags
• Endpoint policies
• Lambda authorizers
• Amazon Cognito user pools

Kong also has several features and plugins for proper access control. These include support for API tokens, keys, OAuth 2.0 support, and OpenID Connect.

Final Thoughts on Broken Access Control

When OWASP declares something the #1 cybersecurity risk, you have to pay attention. While broken access control isn’t limited to APIs, it’s still important to keep in mind. A great number of broken access control risks involve APIs, though, so they’re still of particular interest to API developers.

As we have seen, even one instance of unauthorized API access can expose millions of sensitive user records. As APIs continue to grow in popularity and widespread usage, it’s vital to put policies in place to avoid such widespread cybersecurity risks.