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

In this blog, we will compare the changes of OWASP API Security Top 10 2019 and OWASP API Security Top 10 2023 release candidate.

Author Image

Jaydev Ahire

10 min read


Introduction to OWASP API Security Top 10

Do you remember in 2019, the OWASP (Open Worldwide Application Security Project) launched the API Security Top 10 list, highlighting the most critical security risks faced by APIs? So much has happened in the last 4 years! Tech has evolve rapidly. Which also means API security risks have evolved at the same pace. Not just that, Do you remember when HackcerOne in 2022 published a report saying that APIs are the second most targeted attack vector post website? Well, time to read what’s new in API security!

In this blog, we will compare the changes of OWASP API Security Top 10 2019 and OWASP API Security Top 10 2023 release candidate. We will also explore the new threats introduced in the latest version of the list.

What changed from OWASP API Security 2019 to 2023?

Here is a comparison table for 2023 vs 2019 OWASP top 10 list.

OWASP API 2019 vs 2023

New Categories:

1. New: Server-side request forgery

SSRF is now part of top 10 list. Why, you ask? SSRF attacks have increased massively. Including SSRF in the API Security Top 10 list is logical and expected. What’s SSRF? Server-Side Request Forgery (SSRF) vulnerabilities arise when an API retrieves a remote resource without validating the URL provided by the user. SSRF enables an attacker to manipulate the application into sending a customized request to an unintended destination, even if it is protected by a firewall or VPN. Wow!

is the API vulnerable?

What’s happened over the years? Recent trends in application development have made SSRF vulnerabilities more common and challenging to mitigate. This is because developers  tend to access more and more external resources based on user input. These include webhooks, URL-based file fetching, custom Single Sign-On (SSO), and URL previews. These features help devs significantly enhance the functionality of application. In parallel, they also make it easier for attackers to exploit SSRF vulnerabilities.

To mitigate SSRF risks, developers must implement effective validation procedures. To help developers, we have developed a guide on How to protect against SSRF Attacks? Give it a read and tell us if you like it.

2. New: Unrestricted Access to Sensitive Business Flows

There is another new category in 2023 list top 10 -Unrestricted Access to Sensitive Business Flows. Why so? Most probably, it’s due to the rise of automated threats. Automated threats have become more advanced, profitable, and challenging to safeguard. These threats often target APIs because they are considered easy targets. Good news for hackers! Bad news for security teams.

Why this category is important? Traditional measures like rate limiting and captchas are becoming less effective. Bot-net operators, for instance, can easily circumvent rate limiting by accessing the API from various locations and IP addresses worldwide in seconds.

Moreover, more and more APIs are becoming vulnerable due to exposure to a business flow. Some examples of these flows are purchasing a ticket or posting a comment. Some of these functionalities are implemented without considering how it could impact the business if used excessively in an automated manner.

Here’s an example to explain this: A popular shoe retailer releases a limited edition pair of sneakers that collectors highly demand. The shoes are available for purchase on the retailer's website, but the stock is limited, and the demand is high.

An attacker, who operates a network of automated threats, does the following:

  1. Creates a program that automatically adds the limited edition shoes to their cart

  2. Completes the transaction as soon as they become available for purchase.

  3. Distributes the program across multiple IP addresses and locations to execute the orders. The API lacks adequate protection, allowing the attacker to purchase a significant portion of the limited edition shoes before legitimate users have a chance to make their purchases.

  4. Resells the limited edition shoes on another platform at a much higher price, taking advantage of the high demand and limited supply of the shoes.

  5. Legitimate users are left disappointed, unable to purchase the limited edition shoes at the retail price due to the attacker's automated system.

3. New: Unsafe Consumption of APIs

3rd party APIs make their way into top 10. This new category, Unsafe Consumption of APIs is now part of OWASP top 10 list, as developers often tend to trust third-party APIs but not verify them for security flaws.

This is particularly true for APIs provided by established companies, which may lead developers to adopt less stringent security measures, such as inadequate input validation and sanitization.

OWASP comments

Ensuring secure consumption of APIs requires careful consideration and implementation of security measures at every step of the process.

Monthly product updates in your inbox. No spam.

Monthly product updates in your inbox. No spam.

Monthly product updates in your inbox. No spam.

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

Inection OWASP comments


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.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Follow us for more updates

Experience enterprise-grade API Security solution