Home / Guides / OWASP API Top 10 testing

OWASP API Security Top 10 testing: what a tester checks in each category

OWASP lists ten API risks in its 2023 edition. This guide sets out what a manual test does for each one.

Published · Source: owasp.org

Last reviewed: · 6 min read

The OWASP API Security Top 10 (2023 edition) names ten API risks, from broken object level authorisation to unsafe consumption of third-party APIs. Testing against it means checking each risk with real accounts and requests. Most categories are about authorisation and business logic, so they need two accounts per role and a tester reading responses.

Key takeaways

  • The current OWASP API list is the 2023 edition, API1 to API10.
  • Three of the ten categories are authorisation failures at different levels.
  • Authorisation and business-flow categories need accounts and human judgement to test.
  • Scope the test by endpoint count, roles and tenants.

What is the OWASP API Security Top 10?

According to the OWASP release notes, the 2023 list is the second edition, four years after the 2019 first edition. It is a separate list from the OWASP Top 10 for web applications. Category names are OWASP's own, which is why they keep the US spelling of authorization.

What does a tester check in each category?

Each line is the category as OWASP names it, then what a manual test does with it.

  • API1:2023 Broken Object Level Authorization. Requests another user's object IDs with a second account and checks the server refuses.
  • API2:2023 Broken Authentication. Sends expired, unsigned and wrong-audience tokens, and tries login and reset at volume.
  • API3:2023 Broken Object Property Level Authorization. Looks for fields a role should not see, and sends fields a role should not set.
  • API4:2023 Unrestricted Resource Consumption. Checks rate limits, page sizes, payload sizes and paid calls such as SMS.
  • API5:2023 Broken Function Level Authorization. Calls admin routes directly with an ordinary account.
  • API6:2023 Unrestricted Access to Sensitive Business Flows. Repeats sign-up, checkout or booking flows to see whether abuse is slowed.
  • API7:2023 Server Side Request Forgery. Supplies URLs that point at internal and cloud metadata addresses.
  • API8:2023 Security Misconfiguration. Reviews CORS and TLS in the deployed API, plus headers, error messages and debug modes.
  • API9:2023 Improper Inventory Management. Looks for old versions and non-production hosts that still answer.
  • API10:2023 Unsafe Consumption of APIs. Checks how responses from third-party APIs are validated and whether redirects are followed blindly.

Why can a scanner not cover the whole list?

A scanner sees one request at a time. OWASP's API1 page describes the flaw as a server that does not check whether the caller may access the object it asked for. Proving that needs two accounts and a person comparing what each one gets back. OWASP's API6 page notes that the risk may not involve an implementation bug at all. Each request can be valid on its own.

Why does it matter for Australian API teams?

Customer security questionnaires and ISO 27001 or SOC 2 auditors often ask whether an API was tested against a recognised list. The OWASP API Top 10 is the one most often named. A report that maps each finding to its category is easier for a buyer or auditor to read.

Sorami’s view

This section is opinion. It reflects how we test APIs, not a statement from OWASP.

Start with API1, API3 and API5. They are three levels of the same failure: the server trusting the client about who may do what. They need accounts to test, which is why a test without two accounts per role leaves them unproven.

Before you book, run our free OWASP API Security Top 10 self-check to see which categories you cannot yet answer for. Then bring an endpoint list and an OpenAPI file to the scope.

What to do now

  1. Export an endpoint list or OpenAPI file for every API version still running.
  2. Create two accounts per role, and two tenants if customers share one deployment.
  3. Mark endpoints that take an object ID or call a paid service.
  4. Answer the free self-check and note categories you cannot evidence.
  5. Ask that each finding in the report name its OWASP category.

To have these categories tested on your own API, see API penetration testing, or contact us to discuss scope.

Sources

Facts on this page were checked against these sources on 22 October 2026. We update the page when the source changes.

Questions before you book

Practical answers.

What is the latest OWASP API Security Top 10?

The 2023 edition, API1:2023 to API10:2023. OWASP calls it the second edition of the list. The OWASP Top 10:2025 is a separate list for web applications.

Is OWASP API Top 10 testing the same as an API penetration test?

An API penetration test usually uses the OWASP list as its baseline. It also covers business logic specific to your product. The list is a floor, not a full scope.

Can automated tools test the OWASP API Top 10?

Tools help with misconfiguration, inventory and some authentication checks. Authorisation categories need two accounts and a person comparing responses, so they are tested manually.

What do you need to scope an OWASP API test?

An endpoint count or OpenAPI file, the user roles, whether the API is multi-tenant and the environment to test. Two accounts per role are needed before testing starts.

Let’s scope it

Need your API tested?

Send your endpoint count, roles and an OpenAPI file. We return a fixed scope in writing.

Send an enquiry