What’s coming in the OWASP API Security Top 10 for 2023

A new edition of the OWASP API Security Top 10 is just around the corner, so we decided to take a sneak peek at the work in progress at OWASP to see what’s been trending since the list was first compiled in 2019. While the current work has release candidate status, we’re not expecting any significant changes – and will, of course, follow up with a deep dive as soon as the official list is announced.

Evolution rather than revolution

While, at first glance, many of the category names are different, all the risk categories from the previous edition are still here in one form or another. In the four years that have passed, APIs have gone from extensions of core functionality to a permanent staple of web application architecture. This has brought security issues into sharp focus, allowing categories to be redefined to better match the specific risks observed in actual web environments.

Overall, the release candidate list includes four categories that haven’t changed since 2019, five with changes in naming or scope, and one old standby that makes a new appearance on this particular list.

Broken auth still top of the pile

The whole purpose of an application programming interface (API) is to provide access to something in or from the application, so access control has always been the top security concern for APIs. Accordingly, the #1 risk category hasn’t changed from 2019: Broken Object-Level Authorization. Especially when combined with insecure direct object references, access control failures at the application object level can result in data exposure (as in the Optus breach), allowing malicious actors to freely extract sensitive data via the API.

Closely related is another access control risk that hasn’t changed in name or rank since 2019, namely Broken Function-Level Authorization at #5. This category covers weaknesses that expose application functionality rather than data, though in practice, there is significant overlap between the two. For example, if an attacker can access the export operation for customer records, they could extract sensitive information in bulk even if they cannot access each customer record object separately.

Before any authorization comes authentication, so Broken Authentication had to make the list once again, remaining at #2 (and slightly renamed from Broken User Authentication). This category encompasses all sorts of weaknesses that could allow an attacker to act as a valid user, whether by permitting credential stuffing for brute-force access, failing to verify token signatures, or simply allowing unauthenticated access in some circumstances.

API management as difficult as ever

Other risks that continue unchanged as of this writing are related to API management and administration. Security Misconfigurations remain at #7, covering security issues at any level of the API technology stack that are not directly caused by flaws in the API or application itself. These include unpatched systems, missing or inconsistent security headers, improper permissions on cloud services, and many other configuration-related security risks across complex API stacks.

Improper Inventory Management (previously “asset management”) continues at #9 and will likely remain on the list due to the inherent challenges of managing APIs across their entire lifecycle. As interfaces and their underlying applications both undergo changes (sometimes independently), any gaps in version control and documentation can expose additional attack surfaces in the form of deprecated APIs that are still accessible or undocumented API endpoints that go unnoticed during testing.

APIs are all about automation, so failures to control and limit usage are another mainstay of the API security top 10, slightly renamed to Unrestricted Resource Consumption at #4. These broadly fall into two main categories. Firstly, unlimited API access can expose web services and applications to denial of service (DoS) attacks caused by resource exhaustion when a server in the API stack cannot handle any more requests. Just as importantly, a lack of suitable rate limiting can allow attackers to mount brute-force attacks to, for example, break passwords or enumerate data records.

Broadening risk horizons

Three risk categories have been broadened and redefined to cover a wider range of security issues. Compared to the 2019 list, excessive data exposure and mass assignment risks are now both included under Broken Object Property Level Authorization at #3. This is closely related to object-level authorization failures but applies at a more granular level, where defining and enforcing access control is much harder. Even with proper access control to, say, customer data records, you still need to define who can perform which operations on which data fields, and whether they can import, export, or modify data in bulk.

Renamed from Insufficient Logging & Monitoring, we now see the more descriptive Lack of Protection from Automated Threats category at #8. Malicious bots and other automated attacks make up a large part of web traffic, and APIs are specifically designed for automated access, so it’s crucial to monitor API usage and have the ability to respond if suspicious behaviors are detected. This category is not so much about protection on a technical level as it is about identifying and blocking malicious business logic flows that could result in undesirable outcomes. A typical (and topical) example would be a ticket site not preventing bots from immediately buying up all the tickets for a high-profile event.

Injection flaws have been moved under the wider heading of Unsafe Consumption of APIs (at #10). In this case, “unsafe consumption” refers to using data retrieved from an API without sanitizing and validating it to the same standard as user-supplied data. Especially for communication between APIs (whether internal or external), there is a risk that developers will implicitly trust API behavior without checking if it’s secure. Apart from risking injection attacks via unsanitized data, this could also create encryption gaps or exhaust application resources if the consumed resource provides data at a higher rate than expected.

New yet very old: SSRF

The only new category so far, and also the only vulnerability placed in its own category, is Server Side Request Forgery, currently sitting at #6. This mirrors the choice made for the last OWASP Top 10 in 2021, where SSRF also got its own category for the first time. In the context of APIs, server-side request forgery vulnerabilities allow attackers to smuggle URLs through an API and trick a back-end server into sending a request to that URL. This class of vulnerabilities can be especially dangerous in modern application architectures, where containerized components in the cloud often communicate through APIs over predictable paths, thus greatly increasing the potential for SSRF.

Watch this space

While it may be some time before the final API Security Top 10 arrives, the current release candidate list is unlikely to change much. All the major risk areas for modern APIs are already covered, and the overall trend seems to be towards making the categories more generic to be used more as best-practice guidelines and less as a vulnerability checklist (which was the approach taken for the main OWASP Top 10 list in 2021). That said, the details and examples provided for some categories still vary in terms of format and depth of detail, so it’s likely that work will continue there. We’ll take a detailed technical look at the final list when it arrives, as we did for the 2019 API Security Top 10.