OWASP API Security Top 10 (2023): the ten API risks explained and how to test them

By Kike Gandia · Co-Founder & CEO, OSCP

The OWASP API Security Top 10 is the reference list of the most critical security risks in APIs, published by the OWASP foundation. The current edition is from 2023, and development teams, auditors and customers use it as a shared vocabulary for API security. This guide explains the ten risks with real request examples, what changed from the 2019 edition, which ones a scanner catches and which only manual testing finds, and how to use the list in everyday development without mistaking it for a certification standard.

What the OWASP API Security Top 10 is and why it exists separately from the web Top 10

OWASP (Open Worldwide Application Security Project) is a non-profit foundation best known for the OWASP Top 10 for web applications. In 2019 its API security project published a dedicated list, because APIs fail differently from a traditional website:

They expose objects and functions directly. A website renders on the server what the user may see; an API returns data and lets the client —a SPA, a mobile app, another service— decide what to show. If the API returns too much or does not check who owns each object, there is no interface to cover it up.
Authorization is scattered. Every endpoint, every method and sometimes every field needs its own check. Forgetting one is enough.
There is more surface and less visibility. Old versions still live, internal endpoints published, partner APIs and microservices calling each other.
Classic tools see little. A web scanner finds injections and missing headers, but it does not know that invoice 1043 belongs to another customer.

The current edition is from 2023, released as stable in June that year. It is an awareness document: it ranks the most frequent and serious risks, explains how they are exploited and how to prevent them. It is not a standard with verifiable requirements; for that, OWASP maintains the ASVS (Application Security Verification Standard), whose version 5.0 was released in 2025.

The ten risks at a glance

Code	Risk	What it is in one sentence	Example
API1:2023	Broken Object Level Authorization (BOLA)	The API does not check that the requested object belongs to the requester	Changing an invoice ID in the URL returns another customer's invoice
API2:2023	Broken Authentication	Authentication mechanisms can be bypassed or abused	Login with no attempt limit, tokens that are not validated or never expire
API3:2023	Broken Object Property Level Authorization	The API exposes or lets users modify properties they should not	Sending "role": "admin" in a profile update body and having it saved
API4:2023	Unrestricted Resource Consumption	No limits on requests, size or cost	An endpoint that sends SMS with no limit runs up the provider's bill
API5:2023	Broken Function Level Authorization (BFLA)	A regular user can call administrative functions	DELETE /api/users/77 works with a standard user's token
API6:2023	Unrestricted Access to Sensitive Business Flows	A legitimate business flow can be automated abusively	Bots buying all the stock of a product launch or creating thousands of accounts to claim bonuses
API7:2023	Server Side Request Forgery (SSRF)	The API fetches a URL controlled by the attacker	An “import from URL” field that ends up reading the cloud metadata service
API8:2023	Security Misconfiguration	Insecure configuration at any layer	CORS accepting any origin with credentials, errors with internal stack traces
API9:2023	Improper Inventory Management	Not knowing which APIs, versions and environments are exposed	The /v1 without /v2's controls is still live in production
API10:2023	Unsafe Consumption of APIs	Blindly trusting data from third-party APIs	Storing a provider's response unvalidated and triggering a stored injection

Three of the ten (API1, API3 and API5) are authorization failures, each at a different level: the object, the property and the function. That is no accident: it is what breaks most often in an API and what automated tools see least.

What changed from the 2019 edition

The 2023 edition's release notes highlight four changes: excessive data exposure and mass assignment merged into one category, more weight on resource consumption and two new categories, sensitive business flows and unsafe consumption of APIs. Comparing the two full lists shows the rest of the moves:

2019 edition	2023 edition	What happened
API1 Broken Object Level Authorization	API1 Broken Object Level Authorization	Stays at number one
API2 Broken User Authentication	API2 Broken Authentication	Broadened to authentication of any client, not just users
API3 Excessive Data Exposure and API6 Mass Assignment	API3 Broken Object Property Level Authorization	Merged: both are property-level authorization, one when reading and one when writing
API4 Lack of Resources and Rate Limiting	API4 Unrestricted Resource Consumption	Broadened to cost: memory, storage and third-party service bills
API5 Broken Function Level Authorization	API5 Broken Function Level Authorization	Unchanged
—	API6 Unrestricted Access to Sensitive Business Flows	New: automated abuse of legitimate business flows
—	API7 Server Side Request Forgery	New as a category of its own
API7 Security Misconfiguration	API8 Security Misconfiguration	Unchanged
API9 Improper Assets Management	API9 Improper Inventory Management	Renamed, now including data flows to third parties
—	API10 Unsafe Consumption of APIs	New: the risk of trusting other people's APIs
API8 Injection	—	Dropped as a category of its own; the risk still exists
API10 Insufficient Logging and Monitoring	—	Dropped from the list

Injection no longer having its own category does not mean it stopped mattering: it is still a serious flaw, covered in the OWASP Top 10 for web applications and in the ASVS, and any API penetration test checks for it.

Authorization: BOLA, properties and functions (API1, API3 and API5)

The three authorization risks answer the same question —“may this user do this?”— at three different levels:

API1, the object. GET /api/v1/invoices/1043 returns the invoice even if it belongs to another customer, because the API checks that the token is valid but not that the invoice is theirs. It is the most frequent and most damaging API flaw, and random identifiers do not fix it: a UUID only makes guessing harder, it does not authorize anything. We cover it in depth in the guide to BOLA and IDOR.
API3, the property. It has two sides. When reading, the API returns the full object —with the password hash, the internal cost or other users' emails— and trusts the client to show only what is needed. When writing, it accepts any field in the body: if the update-profile endpoint binds the JSON straight to the model, a user can send "isAdmin": true or "plan": "enterprise" and have it saved. This is the old mass assignment.
API5, the function. A standard user calls an administrative endpoint —/api/admin/users, a DELETE method, a bulk export— and it works, because the route was only “hidden” in the interface. APIs with complex roles, several user types or partner endpoints are the most prone to it.

Prevention is common to all three: a centralised authorization layer applied on every request, to the object, the field and the action; explicit allow-lists of fields returned and accepted, instead of serialising the whole model; and deny by default. Detection is common too: you need to test with at least two users per role and compare what each one achieves.

Authentication: API2 and token abuse

API2 covers everything that lets an attacker pass as another user or another system. In APIs it shows up mainly like this:

Sensitive endpoints with no brute-force protection: login, one-time code verification, password recovery. A six-digit code with no attempt limit gets tried in full.
Badly validated tokens: JWTs accepted without checking the signature, with the “none” algorithm, with a weak key or without checking expiry, issuer or audience.
Credentials in the wrong place: API keys inside a mobile app or a JavaScript bundle, tokens in the URL that end up in logs and Referer headers.
Credential change flows without re-authentication: changing the email or password without asking for the current one lets whoever steals a session keep the account.
Weak service-to-service authentication: microservices that trust any request coming from the internal network.

The details of JWT and OAuth 2.0 —what to validate in each token and which authorization flow mistakes get exploited— are in the guide to JWT and OAuth security in APIs.

Consumption and business abuse: API4 and API6

These two risks do not require a code bug in the classic sense: the API does what it should, but without limits.

API4, unrestricted resource consumption. Every request consumes something: CPU, memory, bandwidth, storage, or money when the API calls a pay-per-use service. Typical scenarios:

Pagination with no maximum: ?limit=1000000 returns the whole database in one response.
Uploads with no maximum size, or image processing with no dimension limit.
Endpoints that send SMS, emails or calls to a paid AI API with no per-user quota: the attack does not take the service down, it arrives on your invoice.
Nested or batched GraphQL queries that multiply server work in a single request.

API6, unrestricted access to sensitive business flows. The flow is legitimate, but automated at scale it does damage: buying all the stock of a limited product to resell it, booking without paying to block availability, creating thousands of accounts to claim a welcome bonus or posting spam from freshly created accounts. The defence is not a generic rate limit but understanding which flows are sensitive for the business and protecting them with specific controls: automation detection, per-account and per-device limits, additional verification at critical steps.

SSRF and third-party APIs: API7 and API10

API7, Server Side Request Forgery. Any feature in which the API fetches something from a user-supplied URL is a candidate: importing a file from a URL, link previews, registering a webhook, generating a PDF from HTML, fetching an avatar from a URL. If the server does not restrict where it can connect, the attacker asks it for internal resources unreachable from outside: admin panels, unauthenticated databases on the internal network, or the cloud provider's metadata service, which in some configurations hands out temporary credentials for the machine's role. That is why an SSRF in an API deployed in the cloud is often the first link in a chain that ends at the data. Defence: allow-lists of destinations, blocking internal and metadata ranges after DNS resolution, not following redirects blindly and using the version of the metadata service that requires a session.

API10, unsafe consumption of APIs. Teams tend to validate what comes from users carefully and simply trust what a provider returns: a payments API, a geolocation API, a data enrichment API. If that provider is compromised or returns something unexpected, the data enters your system unvalidated. Examples: following the external API's redirects without checking the destination, storing text in the database that is later interpreted as HTML or SQL, or having no time or size limits on the response. Defence: treat third-party responses as untrusted input, validate them against a schema, use TLS and pin which destinations are accepted.

Configuration and inventory: API8 and API9

API8, security misconfiguration. It is the broadest category, because it covers the whole stack: the server, the framework, the API gateway, the load balancer and the cloud provider. The most frequent findings:

CORS that reflects any origin and allows credentials, letting any website read the user's authenticated responses.
Error messages with stack traces, versions or SQL queries.
HTTP methods that should not be enabled, or debug routes and interactive documentation exposed in production.
Missing or misconfigured TLS on some leg, for example between the gateway and the backend.
Cache headers that allow responses with personal data to be stored by an intermediate proxy.

API9, improper inventory management. You cannot protect what you do not know exists. Typical cases are the old API version kept “for a few weeks” for customers who have not migrated, still live without the new controls; the staging environment reachable from the internet with real data; undocumented endpoints only the mobile app uses; or data flows to third parties nobody has recorded. Defence: an OpenAPI specification as the source of truth, generated or validated in the pipeline; a version inventory with retirement dates; and periodic discovery of what is really exposed, compared against what is documented. In a pentest, a live endpoint missing from the documentation is already a finding.

How to test each risk: scanner vs manual testing

API scanners add value, especially for configuration and injection, but half the list depends on understanding who each user is and what they should be able to do. In practice it breaks down like this:

Risk	A scanner catches it well	Needs manual testing
API1 BOLA	Barely: it does not know who owns each object	Yes: two or more accounts swapping identifiers on every endpoint
API2 Authentication	Partly: missing limits, unsigned tokens	Yes: recovery flows, MFA, token and session validation
API3 Properties	Partly: obvious sensitive fields in responses	Yes: which fields each endpoint accepts on write, and for which role
API4 Consumption	Partly: missing rate limiting	Yes: business limits, pagination, cost per request
API5 Functions	Little	Yes: a role-by-endpoint-and-method matrix
API6 Business flows	No	Yes: it requires understanding the business
API7 SSRF	Partly, with out-of-band payloads	Yes: confirming what it can reach from inside
API8 Configuration	Well: CORS, headers, TLS, errors	To confirm real impact
API9 Inventory	Partly: route and version discovery	Yes: comparing what is exposed with what is documented
API10 Third parties	No	Yes: reviewing integrations and, better still, the code

The practical conclusion: an automated scan in the pipeline is useful and cheap for API8 and part of API2, API4 and API9; authorization and logic flaws, which leak the most data, need manual testing with several users and roles, ideally starting from the OpenAPI specification or a Postman collection.

How to use the Top 10 in the development lifecycle

Used well, the Top 10 is a checklist for every phase, not just a report reviewed once a year:

Design: for every new endpoint, three questions before writing code: who owns the object, which fields each role can read and write, and what usage limit it has.
Development: centralised authorization instead of checks scattered across controllers; explicit DTOs or input and output schemas; pagination and size limits by default.
Automated tests: authorization tests with two users —“user A cannot read user B's object”— in the continuous integration pipeline. It is the cheapest way to stop a fixed BOLA from coming back in the next sprint.
Inventory: the OpenAPI specification as the source of truth, with alerts when an endpoint that is not in it appears in production.
Independent verification: an API penetration test before major launches and after changes to authentication, roles or integrations.

And two limits worth being clear about. The Top 10 is not exhaustive: it leaves out risks that may be critical in your API, and it does not replace your own threat model. Nor is it a compliance standard: if a customer or an auditor asks for verifiable requirements, the reference document is OWASP's ASVS.

FAQ

How does it differ from the OWASP Top 10 for web applications?

The web Top 10 covers the risks of web applications in general, such as injection or cryptographic failures. The API list focuses on what breaks when an application exposes data and functions through a programmatic interface: above all object-, property- and function-level authorization, resource consumption, inventory and trust in third-party APIs. For an application with an API, use both.

Which is the current version of the OWASP API Security Top 10?

The 2023 edition, which replaced the first one from 2019. Before using the list as a reference in a contract or a report, check the OWASP project's website in case a later edition has been published.

Does an automated API scanner cover the OWASP API Top 10?

Only partly. It catches insecure configuration, missing limits and some authentication problems well, but it barely sees authorization failures (BOLA, properties and functions) or business flow abuse, because it does not know who owns each object or what each role should be able to do. Those need manual testing with several users.

Is complying with the OWASP API Top 10 a legal or certification requirement?

No. It is an awareness document, not a regulation or a certifiable standard. Even so, customers, auditors and security questionnaires often use it as the reference for what an API penetration test should cover. If you need verifiable requirements, OWASP's standard is the ASVS.

Does it also apply to GraphQL, gRPC or WebSockets?

Yes: the risks are protocol-independent. What changes is how they show up. In GraphQL, for example, field-level authorization and nested queries that exhaust the server are especially relevant; we explain it in the GraphQL pentesting guide.

We have never audited our API: where do we start?

With inventory and authorization. First, find out which endpoints and versions are actually exposed and compare that with the documentation. Then, test with two users per role whether one can read, modify or delete the other's data. Those two checks cover the risks that leak the most data in practice.

Sources

Test my API against the OWASP API Top 10