Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer
Noname Security Logo

The Updated OWASP API Security Top 10 for 2023 is Here

Filip Verloy
Share this article

The Open Web Application Security Project (OWASP) is a global non-profit organization dedicated to improving the security of software. The OWASP foundation first released a list of the top 10 security risks faced by APIs in 2019. After a couple of months of healthy debate on the release candidate we now have the finalized updated list for 2023.

Although 4 years is an extremely long time when it comes to computing, the fact remains that most organizations are still in the process of putting better API security controls in place to protect against the 2019 Top 10. Additionally, remember that the list contains ten categories of vulnerabilities, each category housing multiple vulnerabilities.

Comparing the lists, it is of little wonder that the 2023 RC one remains fairly close to the 2019 one, and the final version hasn’t significantly changed either. While #1 remains the same, the rest of the list has new language, new categories, and a shuffling of those that are still from the 2019 version.

API1:2019 Broken Object Level AuthorizationAPI1:2023RC Broken Object Level AuthorizationAPI1:2023 – Broken Object Level Authorization
API2:2019 Broken User AuthenticationAPI2:2023RC Broken AuthenticationAPI2:2023 – Broken Authentication
API3:2019 Excessive Data ExposureAPI3:2023RC Broken Object Property Level AuthorizationAPI3:2023 – Broken Object Property Level Authorization
API4:2019 Lack of Resources & Rate LimitingAPI4:2023RC Unrestricted Resource ConsumptionAPI4:2023 – Unrestricted Resource Consumption
API5:2019 Broken Function Level AuthorizationAPI5:2023RC Broken Function Level AuthorizationAPI5:2023 – Broken Function Level Authorization
API6:2019 Mass AssignmentAPI6:2023RC Server Side Request ForgeryAPI6:2023 – Unrestricted Access to Sensitive Business Flows
API7:2019 Security MisconfigurationAPI7:2023RC Security MisconfigurationAPI7:2023 – Server Side Request Forgery
API8:2019 InjectionAPI8:2023RC Lack of Protection from Automated ThreatsAPI8:2023 – Security Misconfiguration
API9:2019 Improper Assets ManagementAPI9:2023RC Improper Assets ManagementAPI9:2023 – Improper Inventory Management
API10:2019 Insufficient Logging & MonitoringAPI10:2023RC Unsafe Consumption of APIsAPI10:2023 – Unsafe Consumption of APIs

Release candidate changes

As with the 2019 version, the 2023 release candidate still holds firm that business logic based attacks misusing authorization implementations (BOLA) remain the biggest risk category for APIs today and into the foreseeable future.

An API potentially serves many users and provides access to multiple pieces of data, frequently sensitive data. These different users and user types naturally have different data access policies, depending on the business need. From an API design and development perspective, it remains challenging to build an API that correctly enforces these granular authorization policies. We witness this daily as customers test their code using our Active Testing solution.

The new list also consolidates two existing categories under API3:2023RC BOPLA (Broken Object Property Level Authorization). In the 2019 list, they were separated out in:

  • API3:2019 Excessive Data Exposure, whereby the API returns sensitive data to the client by design. This data is expected to be filtered on the client side before being presented to the user, but an attacker can easily sniff the traffic and see the sensitive data.
  • API6:2019 Mass Assignment whereby the sensitivity of internal objects is misjudged, and the API endpoint automatically converts client parameters into internal object properties.

The BOPLA vulnerability is apparent when allowing a user to access an object using an API endpoint, without validating that the user has access to the specific object properties they are trying to access.

New on the 2023 list and somewhat borrowed from the existing OWASP Top 10 2021 is API6:2023RC Server-Side Request Forgery.

Server-Side Request Forgery (SSRF) flaws occur whenever an API fetches a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. Using modern concepts like Webhooks, file fetching from URLs, custom SSO, and URL previews, encourages developers to access an external resource based on user input, heightening the potential risk. Additionally, concepts like microservices based architectures expose control/management plane elements over HTTP using well known paths, making them an easier target.

API4:2023RC Unrestricted Resource Consumption borrows heavily from API4:2019 Lack of Resources & Rate Limiting, with a focus on protecting the available compute and storage resources to successfully serve legitimate API requests. By managing API limits around timeouts, processes, available memory, number of operations, etc., we can prevent an unfair distribution of resources.

API8:2023RC Lack of Protection from Automated Threats, these types of attacks have increased as commercial businesses move more and more to API based systems for eCommerce purposes. Traditional API Gateway and WAF based solutions like rate limiting fall short, as bot-net operators use more distributed approaches to launch their attacks. For these types of attacks, it remains paramount that we identify the malicious traffic and implement automated blocking actions to safeguard the API and allow normal business traffic to continue to flow.

Final version changes

The “new’ ‘ category is API6:2023 Unrestricted Access to Sensitive Business Flows, which is a lack of understanding which business flow your newly created API  exposes. Some business flows are more sensitive than others, in the sense that excessive access to them may harm the business. For example;

A ride-sharing app provides a referral program – users can invite their friends and gain credit for each friend who has joined the app. This credit can be later used as cash to book rides.

An attacker exploits this flow by writing a script to automate the registration process, with each new user adding credit to the attacker’s wallet.

The attacker can later enjoy free rides or sell the accounts with excessive credits for cash.

So identifying the user identity and limiting access or timed access would be a good way to mitigate this type of attack.

The previous API8:2023RC Lack of Protection from Automated Threats was dropped or subsumed by API6:2023 as it mostly addresses a similar issue.

API9:2023 Improper Inventory Management has replaced API9:2023RC Improper Assets Management and matched wonderfully well with the Noname Platform capabilities as it turns out.

How Noname Security Addresses the OWASP Top 10

Noname Security provides the option to view your API issues through the lens of both
the 2019 and 2023 versions. If you use the OWASP list as a guideline in prioritizing
vulnerabilities, it will be easier to link real life findings to the framework.

Download the 2023 OWASP API Security Top 10 Best Practices Guide to learn more.

Filip Verloy

Filip Verloy serves as the Field CTO for the EMEA region at Noname Security. In his role, Filip engages and advises customers, partners and the security industry at large, sharing his experience, insights, and strategies on API security. Prior to joining Noname Security, Verloy was the Field CTO for EMEA at Rubrik, a data security start-up. He has also previously served at various IT vendors including Citrix, Dell, Riverbed, and VMware

All Filip Verloy posts