OWASP API Security Top 10 (2023): A Practical Checklist
The OWASP API Security Top 10 (2023) as a working checklist: each risk, how to test for it, and what Cyron detects in all ten categories. Use it today.
APIs now carry more sensitive operations than traditional web applications: payments, authentication, access to personal data. Yet many teams still apply web-application thinking to API problems. This checklist turns the OWASP API Security Top 10 into three questions per category: what is the risk, how do you test for it, and what does runtime detection catch?
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is OWASP’s list of the ten most serious security risks for APIs. The current edition dates from 2023 and puts broken object level authorisation, or BOLA, first. Each category describes a risk, how attackers exploit it and how to prevent it, which makes the list a practical checklist.
The full list, with attack scenarios and prevention notes, is on the OWASP project site.
The checklist
| Category | The risk | How to test | What Cyron detects |
|---|---|---|---|
| API1 Broken object level authorisation | An attacker changes an object ID and reads or changes someone else’s data: broken object level authorisation | As user A, request user B’s objects by swapping IDs in the path, query string and body | Sequential-ID scanning, bulk enumeration of resources, a success after repeated failures, manipulated identifiers, parameter pollution |
| API2 Broken authentication | Weak login, token or session handling lets an attacker act as another user | Replay many logins against the login endpoint, send a token with alg:none, look for tokens in URLs | JWT attacks: alg:none, empty signatures, expired tokens, kid injection, embedded-key injection, weak secrets. Brute force, credential stuffing, password spraying, tokens in URLs, leaked tokens |
| API3 Broken object property level authorisation | The API exposes fields the caller should not see, or accepts fields they should not set | Compare response fields with what the client displays; add role or price to an update request | Excessive or sensitive field exposure, mass assignment, prototype pollution |
| API4 Unrestricted resource consumption | Requests exhaust CPU, memory, bandwidth or paid services | Send oversized bodies, deeply nested JSON and huge page sizes; flood a WebSocket | Oversized requests, slow responses, deep nesting, pagination abuse, WebSocket floods, gRPC nesting bombs |
| API5 Broken function level authorisation | An ordinary user calls an admin or privileged function: broken function level authorisation | As an ordinary user, call admin routes and other HTTP methods, including method-override headers | Access to functions you mark as restricted, method override |
| API6 Unrestricted access to sensitive business flows | Automation abuses a legitimate flow such as checkout, sign-up or coupons | Script the flow end to end at speed; reuse one coupon across many accounts | Bot user-agents, checkout and purchase velocity, coupon abuse |
| API7 Server-side request forgery | The API fetches an address the attacker chooses, including internal ones | Submit internal addresses, the cloud metadata address and encoded variants to every URL field | Internal addresses, cloud metadata endpoints for AWS, Google Cloud and Azure, encoded addresses, unusual URL schemes |
| API8 Security misconfiguration | Defaults, verbose errors and loose headers hand attackers information | Trigger errors, check security headers and CORS responses, look for debug endpoints | Stack-trace leaks, debug mode, version disclosure, directory listing, missing security headers, wildcard CORS with credentials |
| API9 Improper inventory management | Old versions, test hosts and undocumented endpoints stay reachable | Compare live traffic with your documented inventory; probe old versions and test paths | Deprecated versions, test and staging endpoints exposed, endpoints first seen in the last day |
| API10 Unsafe consumption of APIs | Your API trusts data from third-party APIs without validating it | Feed hostile data through a mocked upstream service; check how redirects and errors are handled | Cyron reports injection here: SQL injection in five variants, cross-site scripting, command injection, path traversal, LDAP, XXE, template injection, NoSQL, XPath and Log4Shell |
Also caught as traffic arrives: ten common attack-scanner fingerprints and headers used to bypass authentication.
How to use the checklist
Work through it in staging, one category at a time. For each row, run the test, write down what happened, and mark it pass or fail. Fix failures in order of exposure: API1, API2 and API5 first, because they hand over data or control with valid-looking requests.
Give every row an owner. Authorisation rows (API1, API3, API5) usually belong to the team that owns the endpoint; API4 and API8 to whoever runs the platform; API9 to whoever keeps the inventory. A failed test with no owner stays failed.
Repeat the run whenever you add an endpoint, change authentication or connect a new third-party API. A checklist that ran once, a year ago, describes an API you no longer have.
OWASP API Top 10: 2019 vs 2023
The 2023 edition kept the core of the 2019 list and reshaped the rest.
- Kept: broken object level authorisation (API1), broken function level authorisation (API5) and security misconfiguration (now API8). Broken user authentication became broken authentication (API2).
- Merged: excessive data exposure (API3:2019) and mass assignment (API6:2019) became API3:2023, broken object property level authorisation.
- Renamed and widened: lack of resources and rate limiting became unrestricted resource consumption (API4). Improper assets management became improper inventory management (API9).
- New: unrestricted access to sensitive business flows (API6), server-side request forgery (API7) and unsafe consumption of APIs (API10).
- No longer separate categories: injection (API8:2019) and insufficient logging and monitoring (API10:2019).
Injection did not stop mattering. Cyron reports it under API10.
Where runtime detection fits
Pre-production tests find flaws in the code you wrote. Runtime detection finds attacks in the traffic you receive, including against endpoints nobody tested. You need both: exploited vulnerabilities were the most common way in, at 31% of breaches, in the 2026 Data Breach Investigations Report.
Cyron API Security has dedicated detection for all 10 categories of the OWASP API Security Top 10 (2023), across five API protocols: REST and HTTP, WebSocket, gRPC, Server-Sent Events and Socket.IO. It analyses a copy of your traffic, so it adds no latency and needs no code changes. For API3, it also checks responses against 50 sensitive-data patterns in six categories, with card numbers, IBANs, routing numbers and national IDs validated to keep alerts clean. Its findings are evidence for your own risk work: Cyron is designed to support your work under GDPR, NIS2, DORA, PCI DSS 4.0 and HIPAA.
The two authorisation categories cause the most confusion. For a side-by-side view, read BOLA vs BFLA vs IDOR.
Five steps for this week
- Export your endpoint list and compare it with live traffic. Anything undocumented is an API9 finding.
- Run the API1 and API5 tests with two test users and one ordinary account.
- Check every URL-taking field for API7 with the cloud metadata address.
- Review error responses and headers for API8.
- Put detection on live traffic, so the next failure is an incident rather than a breach report.
Get coverage for all ten categories
Cyron watches your API traffic for all ten OWASP API Security categories, starting free, with published prices.
Updated 1 October 2026: new title, a checklist with the risk, a test and Cyron’s detections for each category, and a 2019 vs 2023 comparison.