Introduction to the OWASP API Top Ten

February 26, 2020 by

Howard Poston

The OWASP Project

The Open Web Application Security Project (OWASP) is best known for its list of the top ten web application vulnerabilities. This list is updated every few years and is designed to highlight the most common and most impactful vulnerabilities seen in production web applications.

However, the main OWASP Top Ten list is not the only OWASP project in existence. The OWASP umbrella also covers projects for learning about common vulnerabilities, like the deliberately vulnerable Mutillidae and Juice Shop web applications.

OWASP has also expanded their collection of lists to include specific domains like mobile and automated threats against web applications. In 2019, OWASP announced the creation of a top ten list specific to web API vulnerabilities.

The 2019 OWASP API top ten list

The creation of an API-specific top ten list was driven by the increased use of APIs and discovery of vulnerabilities within them. In 2019, 485 new API vulnerabilities were discovered, a 17% increase over the previous year. Since APIs are so powerful and exposed to the public internet, education about the threats that they face is extremely important.

Broken object level authorization

APIs commonly track the identity of a particular user with a user ID embedded in the API request. While this is useful for quickly identifying a particular session, the embedded user ID should not be fully trusted.If an API fully trusts a user ID, then an attacker can substitute another user’s ID number in an API request. If the API does not maintain state on the server, this would enable the attacker to access the other user’s account. This vulnerability is widespread and, according to OWASP, is the most common and impactful attack against APIs.

Broken authentication


Broken authentication APIs are designed to provide access to sensitive data or protected functionality. If an attacker can wrongly access an account on an API, they may be able to steal this data, use functionality that they should not be able to access or perform a denial-of-service (DoS) attack against the API.To protect against this, APIs commonly include authentication to ensure that the requestor is actually the owner of an account. However, authentication mechanisms can be complex, and a simple mistake can render them completely ineffective. As a result, broken authentication is a common and high-impact issue for APIs.

Excessive data exposure

APIs are generally designed to expose data. The purpose of an API is to enable programmatic access to an organization’s online offerings, which enables bulk and low-latency operations with minimal overhead on the client or server side.However, many APIs go overboard on providing data to their clients. The assumption is that a client will perform all necessary filtering, so developers implement APIs using a generic model that does not take into account the possibility of sensitive data in the API response. As a result, someone eavesdropping on communications with an API may be able to extract sensitive data through simple traffic analysis.

Lack of resources and rate limiting

APIs are designed to support automated, programmatic access. This makes them extremely useful for repetitive activities and bulk operations.However, every request made to the API consumes valuable resources on the server side, including network bandwidth, CPU cycles, memory and storage. This makes the API potentially vulnerable to a DoS attack, where the attacker makes frequent, repeated or high-volume requests to consume limited resources. This vulnerability to a DoS attack can exist if the API owner sets rate limiting parameters (such as execution timeouts, request payload size and so on) too high or fails to set them at all.

Broken function level authorization

APIs are designed to do a variety of different things. Some APIs may have a single level of access for all users, while others may have protected functionality only accessible to administrators, “advanced” users and so on.Broken function level authorization is when an API fails to perform checks of an API user’s permissions before granting them access to protected functionality. For example, an API developer may only publicly document publicly available functions, assuming that users will only use these functions. However, if a user discovers and properly calls an administrator-level function, it will run for them. This failure to check permissions on a per-function level and reliance upon “security through obscurity” makes an API vulnerable to attack.

Mass assignment

APIs are often implemented in object-oriented programming languages, meaning that they contain object definitions that consist of a set of properties. In many cases, some of these properties are intended to be defined by a user while others are supposed to be set only by administrators.An issue exists if an API takes a set of user-provided property values and assigns them without checking to see if all of them should be user-controllable. If this is the case, an attacker who determines the underlying structure and business logic of an API’s objects can craft requests allowing them to set protected properties (such as user.is_admin).

Security misconfiguration

APIs are a common target of cybercriminals since they are usually extremely powerful and exposed to the public internet. As a result, any vulnerability in any component of the API’s infrastructure can be a potential attack vector.Failing to properly patch software and endpoints, set permissions on files and so on can give a determined attacker an opening to exploit an organization. Even if an API has all of the patches for known vulnerabilities applied, fuzzing attacks may identify exploitable flaws in the API’s code itself.

Injection

Injection vulnerabilities are some of the most well-known and common vulnerabilities in existence. They rank at the top of the 2017 OWASP top ten list for web application vulnerabilities and third in the 2019 CWE Top 25 Most Dangerous Software Errors list.Injection vulnerabilities exist because many programming languages mix user-provided data and developer-provided code together into a single command. If the developer doesn’t properly sanitize user input, a malicious user can get their data to be interpreted and executed as code. Since APIs take and process user-provided input, they are vulnerable to injection attacks as well.

Improper assets management

The ninth vulnerability on the OWASP Top Ten API Security list refers to a failure to properly track API-related assets throughout their life cycle. As code moves through the development process and the production environment evolves, the purposes of different systems and code can change. If these changes are not tracked, then the system can become vulnerable.For example, an endpoint that an API accesses may become deprecated in a new API version, but it might not be officially removed. If this problem is overlooked, connections to the deprecated system may no longer be monitored or secured.

Insufficient logging and monitoring

As in every other environment, API security should not be “fire and forget.” Acquiring and deploying state-of-the-art cybersecurity solutions is of limited value if no one is monitoring them to determine if they have detected anything of interest. API security systems should be constantly monitored, just like the rest of the organization’s cybersecurity infrastructure, to ensure that they are not undergoing an attack.

Conclusion: The importance of API security

API usage is becoming more common, and APIs are an increasingly visible and tempting target for cybercriminals. The release of an OWASP Top Ten list demonstrates the importance of securing APIs and provides organizations with a good starting point for doing so.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Sources

1. OWASP API Security Project, OWASP
2. The State of Vulnerabilities in 2019, Imperva
3. Category:OWASP Mutillidae, OWASP
4. OWASP Juice Shop, OWASP
5. Foreword, OWASP
6. 2019 CWE Top 25 Most Dangerous Software Errors, Common Weakness Enumeration