API Security Testing: OWASP API Top 10

API securityOWASP API Top 10DASTAPI testingBOLACI/CD security

API endpoints tested against the OWASP API Top 10

The OWASP API Security Top 10 is the reference list most API security testing programmes are built around. OWASP published the current, second edition on 3 July 2023, replacing the first edition from 2019, stating that the API security field had changed significantly in the intervening four years. It ranks ten categories of API-specific risk, each with a short description and a set of prevention steps that double as a testing checklist.

Testing an API is not the same exercise as testing a web page. OWASP's own REST Assessment Cheat Sheet notes that for REST services, inspecting the application itself does not reveal the attack surface: a tester has to collect full requests through a proxy and work out which parameters and object identifiers actually exist. The OWASP Web Security Testing Guide (WSTG) treats API testing as its own chapter, covering REST, SOAP, GraphQL, gRPC and WebSocket APIs as distinct technology families, each with its own discovery and testing considerations.

This post works through all ten categories and how OWASP says to test for each one, then covers the practical approach underneath the list: building an API inventory, turning schemas into test scope, testing authenticated and business-logic paths, and running it all inside CI/CD before release.

The OWASP API Security Top 10 (2023), category by category

OWASP ranks the following ten categories, each with a short description and prevention guidance published on the project's own site. The "how it is tested" column below is drawn directly from OWASP's own prevention guidance for each category, read as a set of checks a tester can run.

Category	What it is	How OWASP says to test for it
API1:2023 Broken Object Level Authorization	APIs that expose object identifiers create a wide attack surface for object-level access control failures.	Swap in another user's record ID and confirm the API denies access rather than returning the record. OWASP recommends writing tests for the authorization mechanism and blocking deployments that fail them.
API2:2023 Broken Authentication	Authentication mechanisms are often implemented incorrectly, letting attackers compromise tokens or exploit implementation flaws.	Map every authentication flow, including credential recovery, which OWASP says should be treated as a login endpoint, and check for anti-brute-force controls and re-authentication before sensitive operations.
API3:2023 Broken Object Property Level Authorization	Merges the earlier Excessive Data Exposure and Mass Assignment categories: APIs returning or accepting more object properties than a caller should see or set.	Compare the properties an endpoint returns or accepts against what the calling role should be authorised to use, and check for generic serialisation methods that return whole internal objects.
API4:2023 Unrestricted Resource Consumption	Missing or badly set limits, such as timeouts, payload size or request rate, let a client exhaust API resources.	Attempt to exceed each documented limit in turn, including execution timeouts, payload size, pagination size and rate limits, and confirm the API rejects the excess.
API5:2023 Broken Function Level Authorization	Complex role and group hierarchies tend to produce administrative endpoints that a lower-privileged caller can still reach.	Call administrative or privileged endpoints as an anonymous or lower-privileged user and confirm access is denied by default, not just hidden from the interface.
API6:2023 Unrestricted Access to Sensitive Business Flows	An API exposes a legitimate business flow, such as purchasing, without controls on excessive automated use.	Attempt to automate the flow at volume and check for the controls OWASP recommends, including device fingerprinting, human-verification steps such as captcha, and blocking known proxy or Tor exit-node traffic.
API7:2023 Server Side Request Forgery	An API fetches a remote resource without validating the caller-supplied URL.	Submit alternative URLs, schemes and redirect targets to any endpoint that fetches a remote resource, and confirm it only accepts allow-listed origins, schemes and ports and does not follow redirects.
API8:2023 Security Misconfiguration	Complex API stacks, including orchestration files and cloud storage permissions, are easy to leave misconfigured.	Review TLS enforcement, enabled HTTP verbs, the CORS policy and security headers, and confirm error responses do not leak stack traces or configuration detail.
API9:2023 Improper Inventory Management	Outdated documentation and untracked hosts or versions make vulnerabilities harder to find and fix.	Inventory every API host by environment (production, staging, test) and version, and confirm older, still-reachable versions get the same security treatment as production.
API10:2023 Unsafe Consumption of APIs	Developers tend to trust data from third-party APIs more than user input, especially from well-known providers.	Validate and sanitise data received from integrated third-party APIs, confirm those connections use TLS, and check that redirect targets are allow-listed rather than followed blindly.

Start with an API inventory, not a scan

API9:2023 exists because most organisations cannot list every API host, environment and version they run. The OWASP Web Security Testing Guide treats this as the first phase of testing: its API Reconnaissance section sets the test objectives as identifying every endpoint supported by the backend, documented or not, finding every parameter for each endpoint, documented or not, and pulling any interesting API-related data out of the HTML and JavaScript sent to clients.

WSTG's recommended technique is to request machine-readable API artefacts early: OpenAPI or Swagger definitions, Postman collections, or the equivalent schema for non-REST APIs. Where no documentation is offered, it recommends checking known documentation paths, spidering the application through an intercepting proxy, and analysing client-side JavaScript for endpoint references. OWASP's REST Assessment Cheat Sheet makes the same point from a different angle: for REST APIs, inspecting the running application does not reveal the attack surface, so a tester has to capture real traffic through a proxy rather than relying on the interface alone.

This is also where continuous, traffic-based discovery differs from a one-off scan. Levo.ai's discovery sensor is built to observe live traffic without changing the application: its own documentation states the sensor requires no SDKs, no code changes, no configuration changes, no sidecars and no runtime agents, and it derives an OpenAPI schema for the endpoints it finds. That auto-generated schema then becomes the input to automated OWASP API Top 10 testing in CI/CD, rather than a separate manual step.

Evaluating Levo.ai?

Get a 14-day free trial with expert onboarding from SecOpsTool, or compare it with the alternatives first.

Start Free Trial →All tool comparisons →

Turn API schemas into test scope

Once endpoints and their parameters are known, testing tools need a way to turn that inventory into test cases without a human writing each request by hand. This is where API schema formats matter in practice: OpenAPI/Swagger, WSDL for SOAP, GraphQL schemas and Postman collections are the common ways a tool learns what an API accepts.

Each of the supplied tools in this category documents its own schema support. Bright Security's API discovery accepts Swagger 2+, OpenAPI 3+ and Postman 2+ definitions, and separately supports GraphQL testing either through introspection of a live endpoint or an uploaded GraphQL schema file. Burp Suite DAST ingests Postman collections, OpenAPI definitions, SOAP and GraphQL definitions to build its scan scope. Acunetix, now marketed by its vendor as Invicti Web + API, imports Swagger/OpenAPI files, RAML, WSDL and WADL files, Postman collections v2 and GraphQL files. Levo.ai takes a different route into the same problem: rather than requiring a schema upload, it derives an OpenAPI schema directly from observed traffic and then runs schema and contract conformance testing so that a change which breaks the published contract is caught before it reaches production.

Test behind the login, and test the business logic

Several of the highest-ranked OWASP API categories only show up once a tester is authenticated as a real user and is testing what that user is and is not allowed to do. For API1:2023 Broken Object Level Authorization, the WSTG testing methodology is to identify endpoints that accept an object identifier, then manipulate it, for example changing a user ID in the request path, across every HTTP method the endpoint supports. A 200 OK response for another user's object indicates the flaw; a correctly authorized endpoint should return 401 or 403 instead. API3:2023 Broken Object Property Level Authorization applies the same logic one level down, to individual fields inside a returned or accepted object.

API6:2023 cannot be reduced to a single request-response check: OWASP describes exploitation as requiring an understanding of the business model behind the API, then automating access to a sensitive flow in a way that harms the business, and its prevention guidance is correspondingly behavioural rather than a single test case.

For the supplied tools, authenticated and behavioural testing shows up in different places. Bright Security documents dedicated authentication methods for scanning behind a login, including browser-based form authentication, OIDC/OAuth and custom multi-step API authentication. Levo.ai publishes a dedicated documentation page for each OWASP API Top 10 category, including one titled API A1 - Broken Object Level Authorization, and runs those category tests automatically in CI/CD. Sec1's API security product page names OWASP API Top 10 coverage alongside detection of shadow and zombie APIs and of PII, PHI and PCI data moving through API responses.

Put API testing in the CI/CD pipeline

OWASP's own prevention guidance for API9:2023 Improper Inventory Management makes the CI/CD connection explicit: it recommends generating API documentation automatically by adopting open standards and including that documentation build in the CI/CD pipeline, precisely so the inventory used for testing does not drift out of date between releases.

Each supplied tool that runs automated scans documents specific CI/CD integrations. Levo.ai ships an official GitHub Action for running tests on every pull request, a Jenkins pipeline step, and Bitbucket Pipelines support. Bright Security documents integrations with GitHub Actions, GitLab, Jenkins, CircleCI, Azure Pipelines and TeamCity. Burp Suite DAST documents dedicated CI/CD guides for Jenkins, GitHub Actions, GitLab, Azure DevOps and TeamCity. Running the same checks on every pull request, rather than only before a periodic manual assessment, is what closes the gap between the inventory built during discovery and what is actually live in production by the next release.

Matching tools to the testing approach

The five categories of testing above, discovery, schema-based scanning, authenticated and business-logic testing, and CI/CD gating, map onto what each supplied tool documents about itself.

Levo.ai - agentless discovery from live traffic, automatic OpenAPI schema generation, OWASP API Top 10 tests with a dedicated page per category, schema and contract conformance testing, and CI/CD integrations for GitHub Actions, Jenkins and Bitbucket Pipelines.
Bright Security - a DAST platform scanning web apps, REST and SOAP APIs, GraphQL and mobile server-side targets; imports Swagger 2+, OpenAPI 3+ and Postman 2+ schemas; supports GraphQL introspection and dedicated authenticated-scanning methods; states coverage across OWASP Top 10, API Top 10 and LLM Top 10.
Sec1 DAST - documents OWASP API Top 10 coverage alongside PCI DSS 4.0.1, GDPR, HIPAA and SOC 2 Type II references, plus detection of shadow and zombie APIs and of PII, PHI and PCI data exposure.
Burp Suite - manual testing tools such as Proxy, Repeater and Intruder, plus Burp Suite DAST, which ingests Postman, OpenAPI, SOAP and GraphQL definitions, checks against PCI DSS and the 2021 OWASP Top 10, and integrates with Jenkins, GitHub Actions, GitLab, Azure DevOps and TeamCity.
Acunetix, now marketed as Invicti Web + API - states it identifies 7,000-plus issues including OWASP Top 10 and OWASP API Top 10; imports Swagger/OpenAPI, RAML, WSDL, WADL, Postman v2 and GraphQL files; lists Multilayer API Discovery and Stateful API Security as named plan features.

Next steps

The OWASP API Security Top 10 gives a fixed, ten-category checklist; the practical work is building an inventory that stays current, feeding real schemas into a scanner, testing what happens once a caller is authenticated, and repeating all of it on every pull request rather than once a year.

If you already have an API inventory or an OpenAPI/Postman collection, the next useful step is a scoping call to map that inventory against the ten categories above and against your existing CI/CD pipeline, so you can see which categories are already covered by an existing scanner and which still need a dedicated API testing tool. You can request that scoping call, or start evaluating one of the tools named above against your own API estate, through SecOpsTool.

Questions Buyers Ask

What is the difference between the OWASP Top 10 and the OWASP API Security Top 10?

The OWASP Top 10 covers general web application risks, while the OWASP API Security Top 10 is a separate, API-specific list of ten risks, such as broken object level authorization and unsafe consumption of APIs, first published in 2019 and updated on 3 July 2023.

How often does OWASP update the API Security Top 10?

OWASP published the first edition in 2019 and the current, second edition on 3 July 2023, four years later, stating that the API security field had changed significantly since the first release.

Can an automated scanner alone find every OWASP API Top 10 risk?

Not reliably for every category. API6:2023 Unrestricted Access to Sensitive Business Flows, for example, requires understanding the underlying business process, and OWASP's own prevention guidance for it focuses on behavioural controls such as device fingerprinting and human verification rather than a single automated request-response test.

Sources

Primary documents this article is based on. Regulatory clauses and product statements above are taken from these pages.

SecOpsTool Security Team

Cybersecurity Specialists

API Security Testing: Covering the OWASP API Top 10