The Gartner API Security Report

Download report

OWASP API Security Top 10 Explained

Michael Isbitski
Michael Isbitski
Jan 27, 2021

As API-related security incidents and breaches increased in recent years, the Open Web Application Security Project (OWASP) released the first-ever API Security Top 10 at the end of 2019 to raise awareness about the most common API security problems plaguing organizations. In this post and subsequent additions to the series, I dig into each of the OWASP API Security Top 10 in detail. I also provide examples and insight to help you understand how to protect your organization from the threats targeting APIs and API-based applications. We start with API1:2019 Broken Object Level Authorization, the most common API threat, represented in about 40% of all API attacks.

API1:2019 Broken Object Level Authorization


APIs often expose endpoints that handle object identifiers, creating a wide potential attack surface. Object level authorization is an access control mechanism usually implemented at the code level to validate a user’s ability to access a given object. Authorization and access control mechanisms in modern applications are complex and wide-spread. Even if an application implements a proper infrastructure for authorization checks, developers often forget to apply these checks before accessing an object.

Attackers can easily exploit API endpoints that are vulnerable to broken object level authorization (BOLA) by manipulating the ID of an object that is sent within an API request. These vulnerabilities are extremely common in API-based applications because the server component usually does not fully track the client’s state. Instead, the server component usually relies on parameters like object IDs sent from the client, to decide which objects can be accessed.

Any access of unauthorized data is severe, regardless of its data classification or data sensitivity. These types of authorization flaws are also not easily detectable with automated static or dynamic testing.

Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object level authorization checks. These checks should be made continuously throughout a given session to validate that the logged-in user has access to perform the requested action on a requested object.

Learn how app architecture and attack surfaces are changing, how app security needs to evolve, and how to empower security.

Potential Impact

Failure to enforce authorization at the object level or broken improper object level authorization can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data.  BOLA can also lead to full account takeover such as in cases where an attacker can compromise a password reset flow and reset credentials of an account they aren’t authorized to.


In this example, the backend logic of the application queries the database with the userId in the query parameter while verifying the authorization with the userId in the cookie. Under normal conditions these two values should match, however, an attacker could simply modify the userId value in the query parameter in order to access unauthorized data.

The attacker (John Smith) is logged in with userId 207939055. When the attacker changes the userId in the query parameter to userId 207938044 the application does not validate that the userId of the authenticated user matches that of the record being requested in the query parameter or whether the authenticated user is authorized to view that given record. As a result, the database backend returns the record for David Miller as opposed to John Smith.

If the userIds are sequential the attacker can simply enumerate the query parameter userId value to scrape, or exfiltrate, large amounts of data, particularly if rate limits aren’t enforced.

Real World Example

How I could have hacked your Uber account

In 2019 a security researcher disclosed a BOLA vulnerability that would have enabled an attacker to take over any user account on Uber. By exploiting the vulnerability, the attacker could access another user’s account to track the target user’s location, take rides, and more. The attacker could also exploit the BOLA vulnerability to harvest Uber mobile app access tokens, and then use those access tokens to take over Uber Driver and Uber Eats accounts. The Uber application userId could be easily enumerated by supplying a user’s phone number or email address in another API request.

Why Existing Tools Fail to Protect You

Traditional security controls like WAFs and API gateways miss these types of attacks because they don’t understand API context and don’t baseline normal API usage. In this case, these tools do not know that the userId in the query parameter and the userId in the cookie should match. Also consider that since this is not a known, predictable attack pattern like a code injection where basic pattern matching and message filtering can be employed, it won’t be identified by the signatures used by a WAF or API gateway.

How to Protect Against BOLA Attacks

In order to prevent BOLA attacks an API security solution must be able to learn the business logic of an API and detect when one authenticated user is trying to gain unauthorized access to another user’s data. In this particular case, two objects should match and that the authenticated user is authorized to access the requested object. This kind of detection requires the analysis of large amounts of API traffic in order to gain context and understand the normal usage for each API. A solution with a baseline of normal usage can identify abnormal behavior like an attacker manipulating the userId in a query parameter in GET requests, or a userId variable within a message body of POST requests.

Next posts:

API2:2019 Broken User Authentication

API3:2019 Excessive Data Exposure

API4:2019 Lack of Resources & Rate Limiting

API5:2019 Broken Function Level Authorization

API6:2019 Mass Assignment

API7:2019 Security Misconfiguration

API8:2019 Injection

API9:2019 Improper Assets Management

API10:2019 Insufficient Logging & Monitoring

Go back to blog