OWASP API Security Top 10 self-check
Ten questions, one per 2023 category, scored in your browser. Nothing is sent anywhere and no email is asked for.
Sorami Consulting built this self-check against the OWASP API Security Top 10 2023, which is still the current API edition. There is no API 2025 list. OWASP Top 10:2025 is the separate web application list. Answer one question per category to see which API risks you can evidence and which a test should target first.
Where your API stands against the 2023 list
Ten questions, one per OWASP category. Yes means you can show evidence, no means a known gap, and unknown means you have not checked.
10 questions. Answer them all and your score appears here.
Nothing is sent anywhere. The scoring runs in your browser.
Self-assessment. Not a penetration test.
If a category came up no, the scope builder turns it into a test scope you can send.
No. The API list is the 2023 edition.
OWASP published the API Security Top 10 2023 as the second edition of the list, four years after the 2019 first edition. Its release notes explain the changes. Excessive data exposure and mass assignment were merged into API3. Unrestricted Access to Sensitive Business Flows and Unsafe Consumption of APIs are new.
The OWASP Top 10:2025 is a different project. It is the web application list, numbered A01:2025 to A10:2025. We checked both pages on owasp.org on 5 October 2026. If OWASP publishes a new API edition, this page will change to match it.
What each question checks.
| Category | The question | Why it matters |
|---|---|---|
| API1:2023 Broken Object Level Authorization | Does every endpoint that takes an object ID check, on the server, that the caller may access that object? | OWASP asks for object-level checks wherever a user-supplied ID reaches data. Include same-role accounts and separate tenants where applicable. |
| API2:2023 Broken Authentication | Are token signatures, expiry and audience validated on every request, with login and password reset rate limited? | A token that is accepted unsigned or expired lets anyone become anyone. Unthrottled login and reset endpoints invite credential stuffing. |
| API3:2023 Broken Object Property Level Authorization | Do responses return only the fields each role may see, and do updates ignore fields the caller may not set? | This category merges the 2019 excessive data exposure and mass assignment risks. Returning the whole object or binding the whole request body is how both happen. |
| API4:2023 Unrestricted Resource Consumption | Are request rates and payload sizes limited? Are page sizes and batch operations bounded, with spending limits on paid calls such as SMS? | Without limits one client can exhaust the service or run up a bill. OWASP lists spending limits on integrations as part of the fix. |
| API5:2023 Broken Function Level Authorization | Is every administrative or privileged endpoint denied to ordinary users by a server-side role check, whatever the client shows? | Hiding an admin button does not remove the admin route. Attackers call the endpoint directly. |
| API6:2023 Unrestricted Access to Sensitive Business Flows | For flows such as sign-up, checkout or booking, have you decided how automated abuse is detected and slowed? | Each request can be valid while the volume harms the business. OWASP notes this does not need an implementation bug. |
| API7:2023 Server Side Request Forgery | Where the API fetches a URL a user supplied, is the destination checked against an allow list that blocks internal and metadata addresses? | A fetch from inside your network can reach services a firewall hides. In cloud that often includes the instance metadata endpoint. |
| API8:2023 Security Misconfiguration | Are TLS and CORS configured deliberately in production? Are applicable security headers and error handling set, with stack traces and debug modes off? | OWASP includes insecure defaults and verbose errors in this category. Check configuration in the deployed environment rather than assuming a framework protects it. |
| API9:2023 Improper Inventory Management | Do you hold a current list of every API host and version that is reachable, including old versions and non-production ones? | Old versions keep old bugs. You cannot test or retire an endpoint nobody knows is still running. |
| API10:2023 Unsafe Consumption of APIs | Is data from third-party APIs validated and limited like user input, over TLS, with redirects not followed blindly? | Attackers can go after an integrated service instead of your API. Trusting its responses moves its weakness into your system. |
Source. Category names and order from the OWASP API Security Top 10 2023. The questions and the reasons are Sorami's wording.
What each band means.
- 0 to 4 yes. Several categories have no control you can show.
- 5 to 7 yes. Some categories covered, some assumed.
- 8 to 10 yes. Most questions were answered yes, not independently verified.
Each no maps to one category in the table above. Use the OWASP descriptions to distinguish object access in API1 from property access in API3 and function access in API5. Review no and unknown answers against the data and business flows you need to protect. The penetration test scope builder turns your answers into a draft scope you can send. Our API penetration testing page sets out what that engagement covers.
What a tester needs for each category.
Most of the ten categories can only be tested with real accounts. API1 and API3 need two accounts in the same role, so the tester can request one account's objects and fields while signed in as the other. API5 needs one account per role, so ordinary users can be pointed at administrative routes. API9 needs a list of every host and version you know about, so the tester can look for the ones you do not.
API4 and API6 need agreed limits before testing starts. A tester checking rate limits or automated abuse of a checkout flow is sending volume on purpose. The testing window and the rate of requests belong in the rules of engagement. API7 and API10 need to know which features fetch URLs or call third parties. That is usually in the API documentation or an OpenAPI file, and helps the tester identify those integrations.
The limits of a self-assessment
- Not a penetration test. Nothing here sends a request to your API.
- Not a certification. OWASP does not certify APIs.
- One question per category cannot cover every case OWASP lists.
- Unknown means evidence has not been checked. No means a known gap.
A yes records what you believe is in place. Only testing the running API in each role shows whether it holds.
Practical answers.
Is there an OWASP API Top 10 2025?
No. The current API list is the OWASP API Security Top 10 2023, which its release notes call the second edition after 2019. The 2025 list people find is OWASP Top 10:2025, the web application list. Checked on owasp.org on 5 October 2026.
What is the difference between the OWASP Top 10 and the OWASP API Security Top 10?
They are separate OWASP projects. The OWASP Top 10 covers web application risks, numbered A01 to A10. The API Security Top 10 covers API-specific risks numbered API1 to API10. Its categories distinguish authorisation of objects, properties and functions.
What is BOLA in API security?
Broken Object Level Authorization is API1:2023. It happens when an endpoint takes an object ID from the caller and does not check, on the server, that the caller may access that object. Changing the ID then returns someone else's data.
Is this self-check a penetration test?
No. It is a self-assessment you score yourself. It records what you believe is in place. A penetration test checks those controls against the running API with real requests in each role.
For the engagement itself, see penetration testing and how to scope a penetration test. What a useful report contains is in what a penetration test report should contain. Every free tool is on resources.
Want the no answers tested?
Send the categories you answered no and the API in scope. We confirm scope and fee in writing before any testing.
Last reviewed: