What's changed in OWASP API Security Top 10 2023 Release Candidate from 2019?

Updated categories:

1. Updated: Broken User Authentication is now Broken Authentication

Old definition: Broken user authentication is a common issue in API security. It refers to any situation where the user authentication mechanism of the API endpoint is inadequate or weak in protecting against unauthorized access.

It can happen due to several reasons. These include use of weak or easily guessable passwords, the failure to properly manage passwords or the lack of proper security measures such as two-factor authentication and the CAPTCHA mechanism.

What changed? Our analysis: API2 (2023): Broken Authentication

Here are the new additions to the latest update of this category in 2023 list:

1. Significant Expansion: The title has changed. The new title, Broken Authentication, no longer includes the word "User". The new definition has significant expansion of authentication risks beyond user-based threats.

2. Microservices inclusion: The focus has expanded to encompass microservices, including the potential involvement of machine and service principals in API authentication processes. The reason for this expansion is that microservices are widely popular now and can be vulnerable. The vulnerabilities can occur if microservices can access each other without authentication or if they use weak or predictable tokens to enforce authentication.

3. Addition of new risks: The updated category also introduced new risks to the list, such as allowing users to change sensitive information without password confirmation and failing to validate the JWT expiration date.

2. Updated: Excessive Data Exposure is now part of API3 (2023) Broken Object Property Level Authorization

Old definition: Excessive Data Exposure is a vulnerability that occurs when an application or API returns more data than is necessary for the intended operation. This can occur when an API returns data that was not intended to be accessed by the user or when an application returns data in an unsecured manner. This vulnerability can have serious consequences, as it can expose sensitive information to unauthorized parties and allow attackers to gain access to resources they should not have access to.

What changed? Our analysis: Here are the changes to this category:

1. Part of a new category: It is now part of API3 (2023): Broken Object Property Level Authorization. The OWASP API Security Top 10 2023 has combined the two 2019 categories, Excess Data Exposure and Mass Assignment, into a single category called Broken Object Property Level Authorization.

2. New additions to the Broken Object Property Level Authorization category: Mass Assignment which was earlier a category in itself is now part of Broken Object Property Level Authorization category. It involves the ability of a user to modify or delete a sensitive object's property, which they should not have access to.

Both, Excess Data Exposure and Mass Assignment, emphasize the importance of properly securing API endpoints and ensuring that sensitive data is protected from unauthorized access and modification.

"For flexible API definitions like GraphQL, this becomes even more important. Devs should be careful about query validation here. Attacker simply need to add already-known fields (from other queries) to exploit Mass Assignment or Excessive Data Exposure vulnerabilitiess." - Ankush Jain, CTO at Akto.io

3. Updated: Lack of resources and rate limiting is now Unrestricted Resources Consumption

Old Definition: Lack of Resources & Rate Limiting is a vulnerability that occurs when an API does not properly manage the resources it uses or enforces rate limiting. This can lead to a number of issues, such as a denial of service (DoS) attack, where an attacker floods the API with requests, causing it to exhaust its resources and become unavailable to legitimate users. It can also lead to an attacker being able to access sensitive information or perform unauthorized actions by bypassing rate-limiting controls.

What changed? Here are the changes to this category:

1. Title changes: The title changed from "Lack of Resources & Rate Limiting" to "Unrestricted Resource Consumption"  API4 (2023): Unrestricted resource consumption. While the previous title focused on the lack of resources and rate limiting as vulnerabilities, the new title emphasizes the consequences of such exposures, which can lead to unrestricted resource consumption by threat actors. The guidance still references the threat of abusing API endpoints due to a lack of rate limiting.

Rate limiting is a common method of controlling the number of requests made to an API within a certain time frame, preventing excessive usage and protecting the system from overloading. Without rate limiting, an attacker can exploit this vulnerability by sending a large number of requests in a short time, leading to a Denial of Service (DoS) attack.

New additions: The guideline outlines that an API is vulnerable if limit is missing or set inappropriately. These limits include:

1. execution timeouts,

2. maximum allocable memory,

3. the maximum number of file descriptors,

4. the maximum number of processes,

5. maximum upload file size, and

6. the number of operations to perform in a single API client request (such as GraphQL batching).

7. Third-party service providers' spending limit

These limits play crucial roles in ensuring an API functions correctly and securely.

There have been cases reported where such attacks increased the cloud bill by 50X! - Ankush Jain, CTO at Akto.io‍

4.  Updated: Improper Inventory Management

What changed? Title changed: Improper assets management is now improper inventory management. Maintaining an accurate inventory of APIs is a vital component of safeguarding them. The term "Assets" has been replaced by "Inventory" to emphasize the significance of this task. Failure to keep track of APIs and retirement strategies leads to running unpatched systems, resulting in leakage of sensitive data

A comprehensive API inventory helps organizations to identify potential attack vectors and take steps to mitigate them. Modern applications and their interconnected APIs are becoming increasingly complex, which poses unique challenges. Therefore, it is essential for organizations to have a clear understanding of their APIs and how they interact with external third parties. This includes understanding how data is stored and shared.‍

Removed categories:

1. Removed: Insufficient Logging & Monitoring

API10:2019 Insufficient Logging & Monitoring is removed in 2023 list. There is lack of data to explain why this category was removed.

2. Removed: Injection

There is a thread on GitHub which is discussing why injection should/ should not be part of API top 10. One of the comments says "The team excluded injection because they think it's not specific to APIs. It doesn't matter that recent reports have shown it to be the largest attack vector on APIs. The philosophy is that this T10 should only include things that are uniquely risks to APIs. " Read below

Conclusion:

The changes from OWASP API Security Top 10 2019 to OWASP API Security Top 10 2023 release candidate indicate a shift towards a more comprehensive and in-depth approach to API security. While some threats have remained constant, such as Broken Object Level Authorization and Broken Function Level Authorization, others have evolved, removed or been added to the list, such as Server Side Request Forgery and Lack of Protection from Automated Threats.

This emphasizes the importance of continuously monitoring and updating API security measures to stay ahead of evolving threats.

Ensuring secure API consumption requires careful consideration and implementation of security measures at every step of the process, from design and development to testing and deployment. The latest release of the OWASP API Security Top 10 is a valuable resource for organizations to understand the current state of API security and take proactive measures to mitigate potential risks.

We at Akto are constantly updating our product to include the latest, most common and critical vulnerabilities. For instance, we have already released tests to detect SSRF. You will see a full coverage of new OWASP top 10 in Akto soon.