The OWASP API Security Top 10: What’s new for 2023

The updated OWASP API Security Top 10 list was released earlier this month, offering a fresh take on application-program-interface (API) security weaknesses and risks that most often lead to specific vulnerabilities.

Six of the risk categories remain mostly or partly the same as on the 2019 OWASP API Security Top 10, the first edition of the list. Two older categories were merged, two others have been folded into broader new categories and a completely new category, dealing exclusively with server-side request forgery (SSRF), was added.

"APIs have gone from extensions of core functionality to a permanent staple of web application architecture," observes Zbigniew Banach of Invicti in a recent blog post. "This has brought security issues into sharp focus, allowing categories to be redefined to better match the specific risks observed in actual web environments."

What the OWASP API Security Top 10 is, and how to use it

The Open Web Application Security Project (OWASP) created the API Security Top 10 as one of several spin-offs from its main Top 10 list of pervasive web-application security risks, aka the OWASP Top 10.

"By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this, APIs have increasingly become a target for attackers," says the foreword to the 2023 version of the list. "Although a broader web application security risks Top 10 still makes sense, due to their particular nature, an API-specific security risks list is required."

Web developers, DevSecOps personnel and security practitioners in general can use the OWASP API Security Top 10 as a reference and guide to developing and maintaining safe APIs, especially web APIs.

"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," says the introduction to the 2023 list.

"The goal of this project isn't to replace other top 10 lists, but instead to cover the existing and upcoming top API security risks that we believe the industry should be aware and diligent about," says a later section on methodology and data.

On the main listing page, each category is accompanied by a brief description of the risk, along with a link to another page further explaining that category.

Each of the individual category pages includes information about that particular weakness's exploitability (classified as "Easy," "Average" or "Difficult"), prevalence ("Widespread," "Common" or "Difficult"), detectability ("Easy," "Average" or "Difficult" again) and technical impact ("Severe," "Moderate" or "Minor").

Each entry also includes paragraphs explaining the threat agents and/or attack vectors, how the weakness arises, and what the impact of exploitation might be. It also provides ways to determine if an API might be vulnerable, two or three examples of possible attack scenarios, suggestions for how to prevent that particular sort of weakness, and links to relevant OWASP pages and external references.

Two additional pages are aimed at developers and DevSecOps personnel, detailing and linking to further OWASP resources specifically for them.

"Building secure APIs is crucial," states the DevSecOps page. "Security cannot be neglected, and it should be part of the whole development life cycle."

What's changed and what's the same on the OWASP API Security Top 10

For quick reference, the 2023 list is thus:

Broken Object Level Authorization (No. 1) and Broken Function Level Authorization (No. 5) have changed neither their titles nor their rankings, with the former being one of the most pervasive and easy-to-exploit weaknesses.

"This issue is extremely common in API-based applications because the server component usually does not fully track the client's state," says the Broken Object Level Authorization category page, "and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access."

That category page presents a couple of new attack scenarios and expands the section on vulnerability indicators but is otherwise little changed from the 2019 version. The Broken Function Level Authorization page is even less changed, merely altering some of the language in the informational summary up top. 

Broken Authentication (No. 2) keeps its ranking but trims its title from 2019's Broken User Authentication. It provides new attack scenarios to replace the old ones (and makes clear that failure to limit the rate of login attempts falls into this category), yet the prevention suggestions are mostly the same.

"This category encompasses all sorts of weaknesses that could allow an attacker to act as a valid user," explains Invicti's Banach, "whether by permitting credential stuffing for brute-force access, failing to verify token signatures, or simply allowing unauthenticated access in some circumstances."

Security Misconfiguration (No. 8) has dropped one slot from 2019. While its definitions and vulnerability indicators have remained pretty much the same, the attack-scenario examples have all been replaced and the prevention suggestions greatly expanded.

According to Banach, this category includes "unpatched systems, missing or inconsistent security headers, improper permissions on cloud services, and many other configuration-related security risks across complex API stacks."

Two categories have been renamed but not drastically changed from 2019. Unrestricted Resource Consumption (staying at No. 4), which most commonly leads to denial of service, was formerly Lack of Resources & Rate Limiting, but had its information only slightly redefined. The prevention suggestions are mostly the same, while the attack-scenario examples have been completely replaced.

Staying at No. 9 is Improper Inventory Management, formerly known as Improper Assets Management. It deals with the risks caused by deprecated APIs or endpoints left online. Its information has been expanded a bit and the vulnerability indicators add material about a "data flow blind spot" and categorize older indicators under "documentation blind spot."

Server-Side Request Forgery (No. 7) is entirely new, tailoring some of the material from the main OWASP Top 10 SSRF category to API weaknesses.

"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," explains Banach. "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."

To make room for SSRF, the 2019 categories of Excessive Data Exposure and Mass Assignment were merged into a new category, Broken Object Property Level Authorization (No. 3). While it's true that the older two categories ultimately stemmed from the same root cause — unauthorized access to object properties — the information and the prevention suggestions are less clear than in the old ones, which had the benefit of examples to aid the reader's understanding.

"Even with proper access control to, say, customer data records," Banach explains, "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."

Finally, two categories contain elements of 2019 entries but are mostly new. Unrestricted Access to Sensitive Business Flows (No. 6) borrows a bit from the older (and rather narrowly defined) Insufficient Logging & Monitoring.

But otherwise, it concerns itself with failure to limit rapidly incoming requests from automated scripts, such as those used to race ahead of humans when buying concert tickets or limited-edition sneakers. Such activity tends to result in bad publicity rather than security breaches but could damage a brand's reputation.

Likewise, the 2019 category of Injection is folded into the broader Unsafe Consumption of APIs (No. 10). This still includes our old friend SQL injection, but OWASP redirects the category to concern itself with improperly trusted third-party APIs that may be used by attackers as weakly protected entryways into more secure main services. "In this case," explains Invicti's Banach, "'unsafe consumption' refers to using data retrieved from [a third-party] API without sanitizing and validating it to the same standard as user-supplied data."

The future of the OWASP API Security Top 10

OWASP notes that "the API Security industry has flourished and become more mature" since its first API Security Top 10 list was published in 2019, and "we strongly believe this work has positively contributed to it, due to it being quickly adopted as an industry reference."

This new edition aims to add to that momentum. If you'd like to participate in the ongoing effort, OWASP invites you to visit the main API Security Project page and the GitHub page on how to contribute.