What’s missing from the OWASP API Security Top 10 2023

The OWASP API Security Top 10 for 2023 has been officially released. While the ground covered hasn’t changed much since the previous edition in 2019, the risk categories have been reshuffled and redefined to reflect higher-level concerns in API design and maintenance. The most surprising change is that injection risks no longer have a category of their own despite being a major security concern in design and testing. Let’s break down the list to see what’s changed and how you can use the updated classification in practice.

OWASP API Security Top 10 2023 at a glance

• API1:2023 Broken Object Level Authorization
• API2:2023 Broken Authentication
• API3:2023 Broken Object Property Level Authorization
• API4:2023 Unrestricted Resource Consumption
• API5:2023 Broken Function Level Authorization
• API6:2023 Unrestricted Access to Sensitive Business Flows
• API7:2023 Server Side Request Forgery
• API8:2023 Security Misconfiguration
• API9:2023 Improper Inventory Management
• API10:2023 Unsafe Consumption of APIs

Methodology and changes since 2019

Unlike the main OWASP Top 10 web application security risks, the API-specific list is not data-driven (2019 was only the first edition, while the call for data put out for 2023 didn’t bring in enough responses for a useful statistical analysis). The project team therefore focused on analyzing API security incident reports since 2019 to outline the broad categories and then refined the classification in discussions with industry experts. We covered the release candidate in detail back in March 2023, and now in June, the final 2023 version has been published.

Changes since the previous edition have the stated goal of reflecting developments and observed trends in API security, especially considering how much this space has matured during the past four years. That said, most of them are about tweaking the wording towards more generic categories, with the only significant change being that API8:2019 Injection has been absorbed into the more generic API10:2023 Unsafe Consumption of APIs – not necessarily a good thing, as discussed below. Compared to the release candidate, updates are mostly limited to ranking, with the only big rename being from Lack of Protection from Automated Threats to API6:2023 Unrestricted Access to Sensitive Business Flows.

Broader themes behind the risk categories

In a nutshell, the 2023 list leans heavily towards controlling access, with four risks related to providing access and three to limiting it. The remaining three categories are about knowing what you have, setting it up securely, and validating incoming URLs. The main areas of concern could be summarized as follows:

• Providing access: No less than three types of broken authorization are included, namely on the level of objects, object properties, and functions. Broken authentication is another major risk category – not surprisingly, considering the number of data breach reports that include the words “unauthenticated API endpoint.”
• Limiting access: All API access must be suitably constrained, which includes controlling server resource consumption (to prevent denial of service), the frequency of business-sensitive operations (e.g. to avoid mass data extraction), and generally taking care not to allow too much (that’s the catch-all Unsafe Consumption of APIs category).
• Inventory management: Knowing all your API endpoints and documenting all API operations is crucial for securing the overall environment, especially as research suggests that less than 10% of organizations fully document their APIs.
• Configuration: Security misconfigurations are a common attack vector across web applications and APIs alike. Unless securely locked down and suitably configured, servers can introduce security risks that are beyond developer control.
• Server-side request forgery (SSRF): APIs frequently send and receive URLs, typically to access remote resources. If a user-supplied URL is processed directly and not validated in context, attackers may trick the server into sending requests to unexpected systems, including internal ones.

A missed opportunity to increase awareness of API vulnerabilities

With so many data breaches involving unauthorized access to API endpoints, it definitely makes sense to put authentication and authorization front and center among API security concerns. Yet even as three levels of authorization were given their separate categories, injection risks were completely removed from the list and broadly incorporated under Unsafe Consumption of APIs along with all the other usage-related risks. For a document compiled with security awareness building in mind, this seems a highly questionable choice that could encourage a “someone else’s problem” attitude to handling API requests – including potentially malicious ones.

The decision to bury injection risks out of sight is even more surprising when you consider the (rightful) presence of SSRF as a primary risk category. Server-side request forgery vulnerabilities are caused by failures to verify incoming URLs before using them in requests, which may allow attackers to access internal resources by posing as the targeted system. Insufficient input validation is the common denominator of SSRF and other injection attacks, so a better way to build security awareness might have been to combine SSRF and injection vulnerabilities into one high-level risk category related to insecure input processing.

How to use the API Security Top 10 – and how not to use it

Similar to the main OWASP Top 10, the list compiled for API security is not a checklist in any conventional sense. To quote the document:

The primary goal of the OWASP API Security Top 10 is to educate those involved in API development and maintenance, for example, developers, designers, architects, managers, or organizations.

Considering that security professionals are not named here and (accordingly) vulnerabilities are only given lip service on the list, the project should really be treated as the Secure API Design Top 10. As such, it is a valuable aid for API designers and developers but has limited usefulness for security testing. It is also not intended as an aid to security product selection since most of the categories correspond to business logic risks that can only be identified through manual testing and rectified through secure design.

Every opportunity to remind people about the importance of API security is welcome, but it’s hard to avoid the sense of a lost opportunity with the new Top 10. APIs make up an ever greater part of the overall web attack surface and are being actively targeted, so safely dealing with malicious inputs aimed at APIs and their backend systems is a crucial requirement. Hopefully, this very practical aspect of API security will be reflected in future editions, though we’ll have to wait another four years to find out.

Until then, whenever you refer to the current OWASP API Security Top 10, you’d do well to add “validate all user-controlled inputs” to your copy of the list. And don’t forget to test for vulnerabilities.