OWASP API Security Top 10 Explained: What Each Risk Looks Like

APIs are where the data is, and in most of our web and backend pentests the findings that matter are API findings. The OWASP API Security Top 10 lists the ten risk classes that cause them. The current edition is from 2023. Our founder has spoken about API security at code.talks and GDG Hannover, and the same observation holds every time: most API breaches are not clever exploits, they are a missing authorization check.

This is what each of the ten risks looks like in practice, how we test for it and what fixes it.

The list at a glance

ID	Name	In one sentence
API1	Broken Object Level Authorization	You can read or change objects that belong to someone else by changing an ID.
API2	Broken Authentication	Tokens, passwords or sessions can be guessed, stolen or forged.
API3	Broken Object Property Level Authorization	You can read or write fields you should not see or set.
API4	Unrestricted Resource Consumption	Nobody limits how often or how much you can ask for.
API5	Broken Function Level Authorization	A normal user can call admin functions.
API6	Unrestricted Access to Sensitive Business Flows	A legitimate flow can be automated to cause harm.
API7	Server Side Request Forgery	The API fetches a URL you control.
API8	Security Misconfiguration	Defaults, debug endpoints, permissive CORS, verbose errors.
API9	Improper Inventory Management	Old versions and forgotten endpoints are still online.
API10	Unsafe Consumption of APIs	Your API trusts other APIs more than it trusts users.

API1, API3 and API5: the three authorization risks

Authorization is the biggest problem in APIs, and OWASP splits it in three because each one is missed in a different place.

API1, Broken Object Level Authorization (BOLA, also called IDOR). The endpoint GET /api/orders/18422 checks that you are logged in, but not that order 18422 is yours. In a pentest we create two accounts and replay every request of user A with the token of user B. In the majority of APIs we test, at least one endpoint fails this test. The fix is a check against the owner of the object in every data access, ideally in one central place, and never in the client.

API3, Broken Object Property Level Authorization. The object is yours, but the API returns fields you should not see (another user’s e-mail in a comment author object) or accepts fields you should not set ("role": "admin" in a profile update, often called mass assignment). The fix is explicit response and request schemas per endpoint, not serialising the database model.

API5, Broken Function Level Authorization. GET /api/users is restricted, GET /api/admin/users is not, or the mobile app never shows the button but the endpoint is open. We enumerate endpoints from documentation, JavaScript bundles and mobile apps and call each one with the lowest-privileged account. The fix is deny-by-default at the routing layer and a role check on every function.

API2: Broken Authentication

The common cases are not exotic: no rate limit on login or on password reset codes, JWTs with alg: none or a weak HMAC secret, tokens that never expire, API keys in mobile apps and refresh tokens that survive a password change. RFC 8725 and RFC 9700 describe the current practice for JWT and OAuth 2.0; most of our findings are deviations from them. Fixes: short-lived access tokens, rotating refresh tokens, PKCE for public clients, server-side validation of the algorithm and the audience, and a lockout or throttling policy that is tested.

API4 and API6: resources and business flows

API4 is about limits: an export endpoint that accepts ?limit=1000000, an image endpoint that resizes anything you upload, an SMS verification that costs you money per call. Each of these is a cost or availability problem. Limits per client, per endpoint and per resource type belong in the design, and a quota error should be a normal response.

API6 is newer in the list and harder to automate: nothing is technically broken, but a flow can be abused at scale. Buying all tickets in a drop, scraping a whole catalogue through a search endpoint, creating thousands of accounts for referral bonuses. The fix is a business decision first (which flows are sensitive) and then device fingerprinting, step-up verification or human checks for those flows only.

API7: Server Side Request Forgery

Any parameter that accepts a URL is a candidate: webhooks, avatar import, link previews, PDF generation from HTML. In cloud environments the first target is the metadata service at 169.254.169.254, which hands out credentials. The fix is an allowlist of destinations, resolution of the hostname before the request with a check against private ranges, and metadata services that require a session token (IMDSv2 on AWS).

API8: Security Misconfiguration

Verbose stack traces, Access-Control-Allow-Origin: * with credentials, GraphQL introspection and debug endpoints in production, missing TLS on an internal hop, outdated frameworks. Not spectacular individually, but they give the attacker the map and often the first foothold.

API9: Improper Inventory Management

/api/v1/ still works although the app uses /api/v3/, the staging API is reachable with production data, a partner integration from 2021 has its own undocumented endpoints. We find these with wordlists, certificate transparency logs and old mobile app versions. The fix is an API inventory that is maintained, a retirement process for versions and the same controls on every environment that holds real data.

API10: Unsafe Consumption of APIs

Your backend calls a payment provider, a geocoding service or a partner API and trusts the response: it follows redirects, parses XML with external entities enabled, writes returned strings into SQL. Treat third-party responses like user input: validate the schema, limit the size, use timeouts, and do not follow redirects blindly.

How we test for the ten

An API pentest at Zyberum is grey box: we ask for the OpenAPI or GraphQL schema, two accounts per role and a test environment with realistic data. The work is then mostly manual, supported by our own tooling for the two-account authorization comparison and by a scanner for API4 and API8. Every finding in the report is mapped to the API Security Top 10 ID, scored with CVSS and comes with a request and response pair you can replay.

Where to start if you build APIs

• Put object and function authorization in one place and write tests for it with two users.
• Define request and response schemas per endpoint and reject unknown fields.
• Set limits everywhere and make the quota error part of the API contract.
• Keep an inventory. Delete what is not in it.
• Have the API tested before a large customer asks you to.

For a scoped test see web application and API pentest, or ask us in a free 15-minute call.