What the OWASP API Top 10 is

The OWASP API Security Top 10 is the best-known list of the most critical security risks for APIs. It is published by the OWASP API Security Project, an open community project of the OWASP Foundation (Open Worldwide Application Security Project). The current 2023 edition is the second, four years after the first edition of 2019.

OWASP sees the list as an awareness document. It shows where APIs typically break, but does not replace a testing standard. For the 2023 edition there is no official German translation yet, only for 2019. This page explains the current edition and links each risk to the original source.

The ten risks at a glance

In focus

Three of the ten entries are pure authorization flaws: API1 (BOLA), API3 (BOPLA) and API5 (BFLA). Each checks a different level: Does this object belong to the user? May they change this field? May they call this function?

API1

Broken Object Level Authorization

Access to other users' objects via manipulated IDs (BOLA). The most common and most consequential API risk.

API2

Broken Authentication

Weaknesses in login, tokens, or sessions that allow assuming another identity.

API3

Broken Object Property Level Authorization

Access to or modification of individual object properties beyond one's own rights (BOPLA).

API4

Unrestricted Resource Consumption

Missing limits lead to overload or high costs, for example through expensive queries without throttling.

API5

Broken Function Level Authorization

Calling functions that aren't permitted for one's own role, such as admin actions as a regular user (BFLA).

API6

Unrestricted Access to Sensitive Business Flows

Automated abuse of sensitive workflows, such as mass bookings or purchases.

API7

Server Side Request Forgery

The API is tricked into making requests to internal systems (SSRF).

API8

Security Misconfiguration

Insecure default settings, open debug endpoints, or missing hardening.

API9

Improper Inventory Management

Outdated, undocumented, or forgotten endpoints, shadow and orphan APIs.

API10

Unsafe Consumption of APIs

Blind trust in data from third-party APIs, without independent verification.

The ten risks in detail

API1:2023 Broken Object Level Authorization (BOLA)

The API checks whether a user is logged in, but not whether they may see or change exactly the requested object. Attackers swap the object ID in the request and receive other users' data.

Example: A shop owner retrieves their revenue data via GET /shops/{shopName}/revenue_data.json and inserts the names of other shops one after another.

More on BOLA

API2:2023 Broken Authentication

Weaknesses in login, tokens or sessions allow someone to pose as someone else. Login and reset endpoints are reachable by anyone and therefore a preferred target.

Example: A limit of three login attempts per minute is bypassed by bundling many attempts into a single GraphQL request.

More on Broken Authentication

API3:2023 Broken Object Property Level Authorization (BOPLA)

The API checks access to the object, but not to its individual fields. Attackers read fields they should not see or change fields that should be off limits. BOPLA combines the former risks “Excessive Data Exposure” and “Mass Assignment”.

Example: A user changes the description of their blocked video and sends along an internal field that lifts the block.

More on BOPLA

API4:2023 Unrestricted Resource Consumption

There are no limits for CPU, memory, bandwidth or paid third-party services. Even simple, massively repeated requests cause outages or high costs.

Example: Every click on “Forgot password” triggers a paid SMS. Without a limit, a script sends tens of thousands of them.

More on Resource Consumption

API5:2023 Broken Function Level Authorization (BFLA)

The API does not check whether the user's role may perform a function at all. Regular users thus call admin functions, often just via a different HTTP method or a guessed path.

Example: Instead of GET /api/invites/{id}, an attacker sends POST /api/invites/new and invites themselves as an admin.

More on BFLA

API6:2023 Unrestricted Access to Sensitive Business Flows

Every single call is correct and allowed, but the flow as a whole can be abused automatically, for example purchases, bookings or comments.

Example: At the launch of a limited game console, a bot buys the entire stock and resells it at a higher price.

More on Business Flows

API7:2023 Server Side Request Forgery (SSRF)

The API fetches a URL supplied by the user without checking it sufficiently. The server thus sends requests to internal systems that cannot be reached from outside.

Example: A webhook is set to the internal metadata address of a cloud server and reveals its credentials.

More on SSRF

API8:2023 Security Misconfiguration

Missing hardening, insecure default settings, missing patches or wrongly set TLS, CORS and header configurations, at any level of the API stack.

Example: A logging library evaluates placeholders by default, and a crafted header is enough to execute code on the server.

More on Security Misconfiguration

API9:2023 Improper Inventory Management

Organizations lose track of their APIs. Old versions, forgotten beta or test hosts and undocumented endpoints keep running, often without the protections of production.

Example: A beta host without upstream rate limiting allows brute force on the password reset.

More on Improper Inventory

API10:2023 Unsafe Consumption of APIs

The API trusts data from third-party APIs more than user input and checks it less strictly. Attackers therefore attack the integrated service instead of the API itself.

Example: A compromised storage service responds with a redirect that the API follows unchecked, and sensitive data ends up with the attacker.

More on Unsafe Consumption

What has changed since 2019

The 2023 edition keeps the basic structure of 2019, but sets new priorities:

  • Merged: “Excessive Data Exposure” (2019: API3) and “Mass Assignment” (2019: API6) now together form API3 BOPLA. Both have the same cause, the missing check at field level.
  • New: API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery and API10 Unsafe Consumption of APIs.
  • Sharpened and renamed: “Lack of Resources & Rate Limiting” is now API4 Unrestricted Resource Consumption, with the focus on the consumption itself rather than just throttling. “Broken User Authentication” is now API2 Broken Authentication, “Improper Assets Management” is API9 Improper Inventory Management.
  • No longer on the list: “Injection” and “Insufficient Logging & Monitoring”. Both remain important, see Injection and Logging & Monitoring.
  • Unchanged at the top: BOLA remains API1.

Which risks scanners find and which they don't

The ten risks differ greatly in how they are found:

  • Often detectable automatically: many cases of security misconfiguration (API8), missing limits (API4) and known weaknesses in authentication (API2). They show up in the configuration or in the behavior of individual requests.
  • Testable only with context: BOLA, BOPLA and BFLA (API1, API3, API5) as well as business flows (API6). Whether there is a finding depends on who owns an object, which role a user has and which flow is allowed. This requires several test identities and knowledge of the business logic.
  • Testable only with an overview: Improper Inventory Management (API9) requires knowing all running APIs, including the forgotten ones.

This is exactly where Venedy comes in for the second and third group: with discovery of the real API inventory and with attacks across multiple identities, each with evidence per finding. How Venedy works · Comparison BOLA, BFLA, BOPLA

Frequently asked questions

Is the OWASP API Top 10 available in German?

Officially only the 2019 edition. For the current 2023 edition, OWASP so far offers translations into French, Persian, Indonesian and Portuguese, but not German. This page explains the 2023 edition and links the original text in each case.

How is the list created?

For 2023, OWASP asked publicly for data for the first time, but none was contributed. The list is therefore based on the experience of the project team, review by API security specialists and community feedback on a release candidate.

How often is it updated?

There is no fixed cycle. The first edition appeared in 2019, the second four years later.

What is the difference from the OWASP Top 10 for web applications?

The well-known OWASP Top 10 covers web applications in general. The API Security Top 10 focuses on risks that are particularly common in APIs, above all authorization flaws at object, field and function level. OWASP stresses that it does not replace the other Top 10 lists.

Sources

Keep reading
Why it mattersWhy API Security Matters GlossaryTerms, briefly explained