The Good, the Bad, and The Ugly: Understanding the API Security Top 10 List

Why is OWASP a Good Framework

The Open Web Application Security Project (OWASP) is a nonprofit organization with the purpose to help secure software. They provide data that can give engineering and security teams a better idea of where the most common risks may lie. The 2021 OWASP Top 10, released in November 2021, lists the most critical web application security risks. But OWASP also maintains the API Security Top 10 project which was last updated in 2019. Each category is ranked based on the frequency and severity of the defect.

The API Security Top 10 consists of:

1. API1-2019 Broken Object Level Authorization.

2. API2-2019 Broken User authentication

3. API3-2019 Excessive Data Exposure

4. API4-2019 Lack of Resources & Rate Limiting

5. API5-2019 Broken Function Level Authorization

6. API6-2019 Mass Assignment

7. API7-2019 Security Misconfiguration

8. API8-2019 Injection

9. API9-2019 Improper Assets Management

10. API10-2019 Insufficient Logging and Monitoring

The Good

As the Top 10 lists are updated every two to three years, we see the threat landscape change. For example, SQL injection – which maintained the top spot for a number of years – is now further down on both lists. On the recent OWASP Top 10 list for web app risks, injection flaws hold the third spot. As frameworks are updated and out-of-the-box solutions are available to prevent SQL injection, the risk does not go down but the frequency of attacks is decreased. The same is seen on the API Security Top 10 list where injection flaws have dropped to the eighth spot.

The Bad

There are a lot of things happening in APIs that engineers did not intend. For example, on the API Security Top 10 list, six out of the top seven categories pertain to unexpected data exposure, which means web applications may not display or expose this information through the web application itself. This means that the authentication and authorization of the API itself is flawed, enabling an attacker to view or possibly change data through the API directly.

The Ugly

Though many flaws in web applications can be detected using automated Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), SAST and DAST cannot test access control flaws effectively, if at all. Looking at the numbers, it is safe to say APIs can contain unexpected behaviors. One thing to note, the top 5 in the API Security Top 10 list may not necessarily lead to code execution on a web server, they could lead to a major data breach, exposing personally identifiable information (PII) or confidential data for an organization.

Breakdown the "Broken" API Security Flaws

API1-2019 Broken Object Level Authorization

Broken Object Level Authorization is currently the top threat to APIs. This refers to when an API does not validate object level authorization. For example, an API may be used to read user details and display them on a profile page. The request made to the endpoint could look like this:

A user from the organization 'trinketshop' with the user ID of 1024 should not be able to read user information in another organization. But if the object authorization checks are not in place, this user could also make the following request:

In the event that PII or confidential data is kept, this could lead to a major data breach.

API2-2019 Broken User Authentication

In today's modern architectures, authentication is no longer a simple service. Authentication can be tricky to get right. It isn't a surprise that it is near the top. OWASP says an API is vulnerable if it:

• Permits credential stuffing whereby the attacker has a list of valid usernames and passwords.
• Permits attackers to perform a brute force attack on the same user account, without presenting captcha/account lockout mechanism.
• Permits weak passwords.
• Sends sensitive authentication details, such as authorization tokens and passwords in the URL.
• Doesn’t validate the authenticity of tokens.
• Accepts unsigned/weakly signed JSON Web Token (JWT) ("alg":"none")/doesn’t validate their expiration date.
• Uses plain text, non-encrypted, or weakly hashed passwords.
• Uses weak encryption keys.

The good thing is, many of these tests can be detected during automated SAST and DAST scans and fixed early in the software development lifecycle. But scans cannot differentiate in most cases whether a user is supposed to be able to access a given function or not.

API5-2019 Broken Function Level Authorization

Web applications may contain an admin console or a management page. Broken Function Level Authorization could allow a standard user to access power user-level functions in the API. These power user functions may only be intended to be accessible in the admin/management console but if function level authorization checks are not in place, it may be called directly without having access to the admin page. Here is an example of a request where a user could change their own user permissions to make themselves an admin if authorization checks are not in place:

This flaw also could lead to unintended data exposure. This is a simple example, but when access controls are broken, data can be exposed.

For more help with broken object level authorization, user authentication, or function level authorization, see the OWASP Cheatsheet.

Final Thoughts

As the OWASP Top 10 web applications risk list and the API Security Top 10 list differ greatly, we need to continue to scan and fix and scan and fix some more. APIs are more critical than ever to build modern applications. They allow easy data transmission from one product or service to another, making information available on many systems. At the same time, they also create a desirable attack vector. As we can see from the API Security Top 10, it is very easy to have "unexpected behaviors" with APIs. Veracode's DAST solution can help with detecting a vast array of API flaws, but do not forget to manually test access controls and authorization.