API Security Testing: Beyond the OWASP API Top 10

APIs have become the primary attack surface for most modern applications, not because they're inherently less secure than traditional web apps, but because they expose application logic directly, with fewer of the incidental protections a rendered UI provides. The OWASP API Security Top 10 was created precisely because the standard web Top 10 doesn't map cleanly onto API-specific risks — but even that list is a floor, not a complete methodology.

What the API Top 10 gets right

The list correctly foregrounds Broken Object Level Authorization (BOLA) as the number one API risk, and for good reason: APIs frequently expose resource identifiers directly in the URL or payload — /api/orders/8842 — and the question of whether the authenticated caller is actually allowed to access order 8842 is a check that has to happen on every single object-returning endpoint. Miss it once, in one endpoint added six months after the original API design, and you have an IDOR at scale.

Broken Object Property Level Authorization (a newer addition, formerly grouped under excessive data exposure and mass assignment) is equally important and often invisible in casual testing: an endpoint might correctly check that a user can view their own account object, but still return internal fields — password hashes, internal flags, other users' partial data nested in a response — because the serialization layer returns the whole database record rather than an explicit, minimal DTO. The inverse problem, mass assignment, happens when an update endpoint accepts a full object body and blindly applies every field to the database record, letting a client set fields like role or isVerified that were never meant to be client-controlled.

Unrestricted Resource Consumption covers the rate-limiting and resource-exhaustion risks that are especially acute for APIs because a single authenticated client can often trigger expensive backend operations — report generation, bulk exports, search across large datasets — at a pace no human UI interaction would allow.

Where the list runs out

Workflow and state-machine abuse. Most API test methodology treats endpoints independently, but a lot of real API vulnerabilities live in the sequencing between calls. Can a client call the "approve" endpoint on an order that hasn't been submitted? Can a multi-step checkout be replayed out of order to skip a payment-verification step? These require modeling the intended state machine and then deliberately testing out-of-sequence and repeated calls — something no endpoint-by-endpoint checklist surfaces on its own.

API versioning drift. Deprecated API versions are frequently left running, sometimes with weaker authentication or validation than the current version, because deprecation in practice means "stop pointing new clients at it," not "decommission it." An old /v1/ endpoint with looser input validation is a fully live attack surface as long as the route still resolves.

Shadow and undocumented endpoints. Internal admin APIs, debug routes left over from development, and endpoints generated automatically by a framework's resource scaffolding but never intended for external use are all common findings that live entirely outside whatever OpenAPI spec the team maintains. Testing against the documented spec alone will never find these — they require traffic analysis, JavaScript bundle inspection for API call patterns, and directory/endpoint enumeration.

GraphQL-specific risk. For GraphQL APIs specifically, introspection left enabled in production, unbounded query depth and complexity (letting a single query fan out into an expensive nested traversal), and batching abuse for brute-force attacks are all risks the REST-oriented API Top 10 doesn't fully anticipate.

A more complete testing checklist

• Test object- and property-level authorization on every endpoint that returns or accepts an identifiable resource, with matched low-privilege accounts.
• Diff the API's actual behavior against its documented spec — undocumented parameters and endpoints are common and often under-protected.
• Model the intended multi-step workflows explicitly and test out-of-order, replayed, and skipped-step call sequences.
• Confirm deprecated API versions are actually decommissioned, not just undocumented.
• For GraphQL, test introspection exposure, query depth/complexity limits, and batching-based rate-limit bypass specifically.
• Verify rate limiting and resource quotas are enforced per authenticated identity, not just per IP, since API clients are almost always authenticated.

API surfaces grow faster than most teams' documentation keeps up with, which is exactly why asset inventory matters as much as the testing technique itself — you can't test an endpoint you don't know exists. Venstap's asset management ties discovered API endpoints back to the same scoping and scanning workflow used for web and network assets, so shadow endpoints found during a manual assessment get tracked and re-tested on the same schedule as everything else, rather than living in a one-off pentest report that nobody revisits.