OWASP API Security Top 10 (2023): the list and how to test each risk

The OWASP API Security Top 10 is OWASP's ranked list of API risks. The edition on the OWASP site as of November 2026 is 2023. Its ten items run from API1:2023 to API10:2023. We checked the 2023 list on 2026-11-09 and did not find a newer final edition.

We use the list as the coverage map for API penetration testing. The web counterpart is the OWASP Top 10:2025.

What is the OWASP API Security Top 10 2023 list?#

API3:2023 merges two 2019 items: Excessive Data Exposure and Mass Assignment. The 2019 item "Lack of Resources & Rate Limiting" is now API4:2023 Unrestricted Resource Consumption.

How do testers check each risk?#

API1:2023 Broken Object Level Authorization (BOLA)#

The API lets a caller reach objects that belong to someone else. OWASP says attackers exploit it "by manipulating the ID of an object that is sent within the request." Test ideas:

• Send account B's object IDs with account A's token, in paths, query strings, bodies and headers.
• Test read, update and delete on every object type.
• Check batch, export and search endpoints that return many objects.

The IDOR testing guide gives the full method.

API2:2023 Broken Authentication#

Login, token or recovery flows let someone act as another user. Test ideas:

• Check token expiry, reuse after logout and signature checks.
• Look at password reset and MFA endpoints for weak limits.
• Compare error messages for valid and invalid users.

The authentication testing checklist has more checks.

API3:2023 Broken Object Property Level Authorization#

A caller can read or write a property they should not touch. This includes mass assignment. Test ideas:

• Compare the response fields for a user and an admin. Look for fields such as internal notes or other users' emails.
• Add extra fields such as role or plan to an update request, then read the object back.

PATCH /api/v1/profile HTTP/1.1
Host: api.harbor-notes.example.com
Authorization: Bearer <token-of-test-user-A>
Content-Type: application/json

{"display_name": "Test A", "role": "admin"}

HTTP/1.1 200 OK
Content-Type: application/json

{"display_name": "Test A", "role": "member"}

API4:2023 Unrestricted Resource Consumption#

The API has no sensible limit on request size, rate, cost or count. OWASP says an API is vulnerable if limits such as execution timeouts, memory and file descriptors are "missing or set inappropriately." Test ideas:

• Send a bounded burst of requests to a route and watch for HTTP 429.
• Ask for a very large page size or a deeply nested query, within an agreed limit.
• Check limits on SMS, email and paid third-party calls. Bound the cost and state it in the scope.

See rate limiting and credential stuffing.

API5:2023 Broken Function Level Authorization#

A low-privilege caller can call admin or other-role functions. Test ideas:

• Call every admin route with a member token.
• Change the HTTP method (GET to PUT or DELETE) on a route that only allowed GET.
• Look in client bundles for hidden admin routes.

API6:2023 Unrestricted Access to Sensitive Business Flows#

An attacker can automate a flow, such as buying, booking or signing up, in a way that harms the business. Test ideas:

• Repeat a coupon, referral or reservation action at a bounded rate, with test data.
• Check whether the API tells one user from a script.

The business logic guide covers this theme.

API7:2023 Server Side Request Forgery#

The API fetches a URL that the caller controls. Test ideas:

• Find parameters such as url, callback and avatar_url.
• Point them at a host you control and check the server request. Do not target internal systems unless the scope allows it.

API8:2023 Security Misconfiguration#

Settings leave the API open: verbose errors, open CORS, missing TLS, default credentials. Test ideas:

• Review CORS rules, error output and the HTTP methods allowed.
• Check that production does not expose debug or documentation endpoints without need.

API9:2023 Improper Inventory Management#

Old versions or undocumented endpoints stay live. Test ideas:

• Try /v1/ routes when /v2/ is current.
• Compare the API description with endpoints seen in client code and traffic.
• Check that staging hosts are not public.

API10:2023 Unsafe Consumption of APIs#

Your API trusts data from third-party APIs too much. Test ideas:

• Identify integrations that feed data into your system.
• Check whether you validate that data like user input.
• Check redirects and timeouts when the third party fails.

What does a good API test case look like?#

A test case names the endpoint, the caller, the input, the expected result and the evidence. We run controls beside each exploit request: a nonexistent ID, a correct-owner request and an anonymous call.

How do teams fix these risks?#

Put authorization in one shared layer, and check the owner of each object in every handler or in a policy engine. Allow-list the fields each role can read and write. Set rate, size and cost limits per route. Keep an API inventory, retire old versions, and treat third-party responses as untrusted input.

What does a sample finding look like?#

A finding should let a developer reproduce the issue and verify the fix. This illustrative write-up is not a real result.

What do you need to share before an API test?#

Testers work faster and cover more with clear inputs. Prepare these items.

1. An API description. An OpenAPI file, Postman collection or GraphQL schema. Include internal and mobile-only routes if they are in scope.
2. Accounts. Two per role, plus an admin. Mark them as test accounts.
3. Test data. A known record of each type in each account.
4. Limits. Maximum request rate, forbidden actions (for example no real emails, no card charges) and the test window.
5. A contact. Someone who can pause the test.

Without a description, testers must find routes in client code and traffic. That takes longer and may miss routes the client never calls, which is where API9:2023 problems can sit.