API Security: The OWASP API Top 10, Explained Practically

Web application security guidance was written for applications that render HTML. Modern systems are mostly APIs serving JSON to clients the server does not control. OWASP maintains a separate API Security Top 10 precisely because the dominant failure modes are different — and authorization dominates the list.

Why APIs need their own list

A traditional web application decides what to render server-side. An API hands raw objects to a client and trusts it to display only what is appropriate — which means anything the API returns is effectively public to whoever holds the token.

APIs also expose object identifiers as a matter of design, are consumed by clients the server cannot trust, and change fast enough that documentation, gateway rules and monitoring all drift out of date.

The failures that matter most

• Broken object level authorization (BOLA) — the API-specific form of IDOR and consistently the most commonly exploited API flaw. The endpoint verifies the caller is authenticated but not that they own the requested object.
• Broken authentication — weak token handling, missing expiry, tokens accepted after logout, unverified signatures, or refresh tokens that never rotate.
• Broken object property level authorization — returning fields the caller should not see, or accepting fields the caller should not be able to write.
• Unrestricted resource consumption — no rate limiting or pagination caps, enabling both denial of service and bulk data harvesting.
• Broken function level authorization — administrative operations reachable simply by knowing the path and method.
• Unrestricted access to sensitive business flows — automation abusing a legitimate workflow, such as bulk purchasing or mass account creation.
• Improper inventory management — forgotten staging hosts and deprecated versions still serving live data.

Excessive data exposure in practice

A frequent pattern: an endpoint returns the full user object because the mobile client needs two fields from it. The client displays those two fields, and the rest — email addresses, password hashes, internal flags, tokens — travels to every caller who asks.

Nothing in the user interface reveals this. Anyone inspecting the raw response sees everything. The fix is to serialise explicitly, returning only the fields that endpoint is meant to expose, rather than dumping the model.

Testing an API properly

1. Obtain the specification if one exists, then verify it against reality — undocumented endpoints are common and rarely reviewed.
2. Test with at least two accounts and swap object identifiers between them to detect BOLA.
3. Inspect raw responses rather than the rendered client, looking for fields no caller should receive.
4. Attempt to write properties you should not control, such as role, status, price or ownership fields.
5. Remove, expire and tamper with tokens; check whether signature validation is genuinely enforced.
6. Probe old versions and non-production hosts, which frequently lag behind on fixes.
7. For GraphQL, test introspection exposure, query depth limits and batching abuse.

Defensive essentials

• Enforce object-level authorization inside the data access layer, so no endpoint can forget it.
• Serialise responses through explicit schemas rather than returning models directly.
• Allow-list writable properties on every input.
• Rate limit per identity and per object, not only per IP address.
• Maintain an accurate inventory of hosts, versions and endpoints, and decommission what is unused.
• Log authorization denials and monitor for enumeration patterns.

Related from TechBiz Security

• API security testing
• Web application penetration testing
• Penetration Testing: The Complete Guide

Sources & further reading

• OWASP API Security Top 10
• OWASP API Security Project
• PortSwigger Web Security Academy — API testing
• OWASP REST Security Cheat Sheet

Frequently asked questions