OWASP API Security Top 10 List 2023 Refresh, from one of the project leaders

The OWASP API Security project just released the new version of the OWASP Top 10 for APIs.

The project leaders – Paulo Silva, Erez Yalon, and I – Inon Shkedy, have been working together with the OWASP community to compose a list that represents the Top 10 threats for APIs in 2023.

The OWASP API Top 10 list is an awareness document and should be used together with other resources, such as the traditional OWASP Top 10 (last released in 2021).

In this blog post, I will cover some of the trends in the field of API security. We will see how those trends shaped the new list, which threats became more relevant, and which have been moved off of the list.

Trend #1 – Authorization, Authorization, Authorization

Authorization is the process of verifying that a user is allowed to do what they intend to do. The process is also called “Access Control”. It’s not a secret that authorization issues are the biggest risk of APIs. We can see large companies getting breached because of them daily.

This trend, unfortunately, hasn’t changed since 2019. It seems like protecting against authorization problems is just becoming more and more challenging.

The challenge of authorization in APIs

Why is it so challenging to implement a decent authorization mechanism in APIs?

Since I joined the project in 2019, I’ve been asking myself – “why do we see so many authorization problems in APIs?”.  After extensive research, I believe that some of the main reasons are:

Authorization is a decentralized mechanism

When we think about other security mechanisms, such as Authentication or Rate Limiting, those are usually implemented in one or a few places in the application. For example, some companies have a dedicated team of experienced engineers that is responsible for implementing the Authentication mechanism. 

When it comes to authorization, this is a very decentralized mechanism and authorization checks often need to be done in hundreds or even thousands of different places in the code and the configuration of the API.

Authorization is the responsibility of almost every single engineer in the organization, so the attack surface is much larger, and engineers have more places to make mistakes.

Authorization policies are a mess (in modern apps)

Modern applications, by design, are often planned to serve multiple types of users. Even before getting into implementation (writing the code that allows/blocks the access)  deciding, from a theoretical perspective, which user should have access to what is a complex question.

For example:

• Your health provider app might allow you to create “sub-users” for your spouse or child. It leads to a situation where your user, by design, should be able to read the PII of other users.
• A ride-sharing app might have regional admins. So the East Coast admin should be able to access data of users from New York, but not from California.

The fact that those authorization decisions become more complex, makes it even more difficult to translate them into code that covers all the edge cases without making mistakes.

What are the different types of Authorization Problems?

There is no one way to implement authorization mechanisms. It depends on the industry and the business needs of the API. But after reviewing data from many bug bounty reports and public breaches, we found that engineers tend to make three different types of mistakes when it comes to authorization:

Object Level Authorization – API #1 – BOLA

This type of authorization is the most common problem in APIs. APIs, by design, receive many Object Identifiers from the users.

For example – after I take an Uber ride, I go to my ride history and rate the ride as 5 stars. Since I’ve taken multiple rides in the past, my phone (the client) has to specify to the API which ride I want to rate. This communication is done by sending the Object ID of the ride (in this case, object == ride).

So it would look like: {“ride_id”:515, “rating”:5}

The problem begins when an attacker changes the ID to a ride ID that doesn’t belong to them. If the developers don’t validate that the user is accessing only objects that should be accessed by them, the API is vulnerable to BOLA.

Function Level Authorization – API #5 – BFLA

This type of authorization problem is more intuitive to understand.

The problem begins when you have a user that belongs to a role/group with low privileges (e.g., a “rider” user on Uber) – and they try to access functionality that should be exposed only to higher privileged users (e.g., drivers, admins).

If the engineer doesn’t validate that the user belongs to the right group – a lower-privileged user might be able to access a function that only a higher-privileged user should have access to. This is BFLA. 

Object Property Level Authorization – API #3 – BOPLA

This year, we decided to merge two other types of authorization problems – Mass Assignment and Excessive Data Exposure.

Even if the engineers who built the API validate that a user is allowed to access a specific function (BFLA) and a specific ID (BOLA), the API might still be vulnerable to BOPLA – if they don’t validate that the user has access to change/read the specific object property.

For example, a BOPLA can happen if you join a dating app, start swiping, and look at a profile of someone you find interesting. Behind the scenes, there’s an API call to fetch data about the user.

Since you’re a registered user, you should have access to the API Endpoint and see other users around you (there’s no BFLA)

Since the other user’s profile is public, you should be able to access their profile ID (there’s no BOLA)

But, on the UI, you would only see the public details of the other user, such as first name and picture. An attacker could intercept the traffic, and find that in addition to the public object properties (first name, etc), the API also returns private object properties – such as full name and exact location. Since those object properties are sensitive, and shouldn’t be returned to the user, the API is vulnerable to BOPLA.

Trend #2 – APIs don’t protect their expensive resources

One of the interesting changes in the list is “API#4 – Unrestricted Resource Consumption”.

APIs leverage many different resources and integrations to serve their users. Some of these resources are more expensive or limited than others.

Let’s take two examples:

• As part of the registration process to a bank, the API verifies the identity of the user by doing a background check. The developers use “background check API” – a third-party API – to conduct a background check for every new user. The third-party API charges the bank a couple of dollars for each background check.
  
  In this example, the resource is an API call to “background check API” – which is expensive. An attacker could abuse the registration process to initiate thousands of background checks, which would lead the bank to lose thousands of dollars in a few minutes.
• A CRM system allows its users to generate complex and heavy financial reports. The generation process of these reports takes time and a lot of CPU from the API.
  
  In this example, the resource is CPU – which is limited (and might be expensive as well). The attacker could abuse the report generation process to request hundreds of reports, which would consume all the available CPU of the API, and could lead to Denial of Service.

Trend #3 – Automated threats exploit sensitive business flows

A new item, with a big name, “API #6 – Unrestricted Access to Sensitive Business Flows” covers a concerning trend we see in APIs. Hackers are getting more creative when it comes to making profits out of abusing APIs.

A few examples of this are:

• Scalping – a common phenomenon, where hackers buy all the stock of a high-demand item (such as concert tickets, sneakers, PS5, etc) and then resell them for a much higher price.
• Spamming – hackers use features such as private messages, comments, or posts of an API to spread malicious links or phishing campaigns.
• Denial of inventory – hackers would reserve all the appointments/reservations and prevent other users from getting access to the desired service.

There are two key things in common between the examples above:

1. Sensitive business flows – purchasing a product, sending a private message, or making a reservation are all sensitive business flows. Sensitive, in this context, means that excessive access to the flow might harm the business.
   
   It’s important to realize that, unlike other vulnerabilities, the impact in these cases isn’t usually technical first, but directly impacts the business – losing revenue/customers, etc.
2. The API fails to restrict access to these flows – in these scenarios, the damage that is done is possible because of the lack of usage restrictions at the API level.

The protection against these types of threats is anything but generic. Different industries might define different business flows as sensitive. Even within the same industry, one business could consider a certain business flow as sensitive and another business flow as not. For example, Facebook doesn’t allow automated posts, while Twitter encourages it.

Sensitive Business Flows vs Resource Consumption

Two items on the updated list, this one, “API #6 – Unrestricted Access to Sensitive Business Flows”, and “API #4 – Unrestricted Resource Consumption” might look somewhat similar, but the main differences between them are:

Traditional AppSec vs. API Security 

Some people might read the new list and ask themselves – “where did Injection go?”.

​​Our goal is to increase awareness of the most critical security risks in APIs that need special attention. Injections do not behave differently in APIs, and their exploitation is not different either. On top of that, modern concepts in application development have made injections less and less prevalent. 

Injections used to be the most severe threat when it comes to web applications for many years. Although there are several types of injections, based on past data there are two types of injections that have made this category so severe and prevalent, which are:

• SQL Injection
• Command/Shell Injection

These types of injection are less common in API-Centric applications that have been developed in recent years, because of the following reasons:

• More developers choose to use ORM environments that protect against most types of SQL Injections by default. Even though it is possible to write vulnerable code while using an ORM – it is much less common.
• With the rise of Cloud Native, it is less common to see developers using shell commands inside the application code. Doing so makes the application less scalable in the Docker/Kubernetes environments.
• It is no longer common to see developers using shell commands to leverage CLI tools (for example: for graphics purposes). Modern frameworks and the abundance of third-party libraries/APIs, make this trend less common in modern applications since it is easier to find a library you can call within the code itself, instead of a CLI tool.
• Hundreds, if not thousands, of solutions, have been built around SQL/Shell Injection protection.

Injections not being in the API Security Top 10 list does not mean that you can’t find Injections in APIs. Injections still happen (mostly in traditional applications), but we see protecting against them as a part of common practices for general application security.

Similar reasoning also applies to other removed categories, such as “Vulnerable and Outdated Components”.

What’s next?

Creating the 2023 list was a challenging, fun, and enlightening journey. We talked with many experts in the field and learned of many new trends since the last list was published. We hope that companies and individuals will find the list helpful in navigating the battleground of API security and that they will improve their security posture by learning from the list, and by implementing some of the ideas in it.

We look forward to following the new trends over the next few years as API vulnerabilities and exploits continue to grow and change, and we will continue to evolve the list accordingly.

About Traceable

Traceable is the industry’s leading API Security company that helps organizations achieve API protection in a cloud-first, API-driven world. With an API Data Lake at the core of the platform, Traceable is the only intelligent and context-aware solution that powers complete API security – security posture management, threat protection and threat management across the entire Software Development Lifecycle – enabling organizations to minimize risk and maximize the value that APIs bring to their customers. To learn more about how API security can help your business, book a demo with a security expert.