# API Security Testing: The OWASP API Top 10 in Practice

> Updated 2026-10-25 - 11 min read

The OWASP API Security Top 10, updated in 2023, is the standard reference list for API vulnerability categories - but knowing the list and actually testing an API against it are different skills. Here's what each of the ten categories looks like in a real engagement, not just in the abstract.

## API1: Broken Object Level Authorization (BOLA)

The single most common and most damaging API flaw: changing an ID in a request (/orders/1234 to /orders/1235) returns another user's data because the API checks that the object exists, but not that the requesting user is allowed to see it.

## API2: Broken Authentication

Weak token handling, missing rate-limiting on login or password-reset endpoints, or JWTs validated for structure but not properly for signature and expiry.

## API3: Broken Object Property Level Authorization

A user can read or write specific fields on an object they shouldn't - excessive data exposure (an endpoint returns more fields than the UI displays, including sensitive ones) or mass assignment (a request can set a field, like "isAdmin", that was never meant to be user-settable).

## API4: Unrestricted Resource Consumption

No limits on request size, response size, number of results returned, or rate of requests - letting a single client exhaust resources or run up costs, whether by attack or just a buggy integration.

## API5: Broken Function Level Authorization (BFLA)

An authenticated regular user can call an admin-only endpoint directly, because the API doesn't re-check role or permission at each function, only at the UI layer.

## API6: Unrestricted Access to Sensitive Business Flows

New in the 2023 list: automatable abuse of a legitimate business flow at scale - bulk-purchasing limited-stock items, mass account creation for a referral bonus - that isn't a traditional "vulnerability" but still causes real business harm.

## API7: Server-Side Request Forgery (SSRF)

An API that fetches a URL on the caller's behalf - webhooks, image-fetch-by-URL, PDF-from-URL features - without validating the destination can be tricked into reaching internal infrastructure the caller shouldn't be able to touch.

## API8: Security Misconfiguration

Verbose error messages leaking stack traces, permissive CORS policies, default credentials left active, or missing security headers - often found quickly but easy to miss across a large API surface.

## API9: Improper Inventory Management

Old API versions left running and unmonitored, undocumented "shadow" endpoints, or staging and debug endpoints accidentally exposed in production - all expanding the real attack surface beyond what's officially documented.

## API10: Unsafe Consumption of APIs

Trusting data from a third-party API integration without the same validation you'd apply to user input - a compromised or malicious upstream API becomes a direct path into your own system.

## GraphQL adds its own layer on top

Introspection left enabled in production, query depth/complexity abuse (a deeply nested query that's cheap to write but expensive to execute), and batching attacks - these map onto the same ten categories but need GraphQL-specific testing technique.

## FAQ

**Is REST or GraphQL more vulnerable?**
Neither inherently - the underlying flaw categories (broken authorization, resource consumption, misconfiguration) apply to both, though GraphQL's flexible query structure creates some additional attack surface (introspection, query complexity) that REST doesn't have in the same form.

**Can automated scanning find these issues?**
Partially - automated tools catch some misconfiguration and known-pattern issues, but BOLA, BFLA and business-logic flaws like Unrestricted Access to Sensitive Business Flows require understanding what the API is actually supposed to do, which is fundamentally a manual-testing problem.