API Security Checklist: What to Test Before Launch

Your API is very often the shortest path between an attacker and your actual data — shorter than the web application in front of it, because an API frequently returns raw data with none of the client-side rendering that might otherwise obscure what’s there. If it’s never been tested specifically, here’s what actually matters before it handles real user data in production.

The One Thing Worth Testing First: Object-Level Authorization

If there’s a single highest-priority item on this list, it’s this: does every endpoint verify that the requesting user actually owns the object they’re asking for, not just that they’re authenticated at all?

This is Broken Object Level Authorization (BOLA), and it’s ranked #1 in the OWASP API Security Top 10 for a simple reason — it’s both extremely common and requires almost no sophistication to exploit. The canonical example: an authenticated user changes /api/accounts/123 to /api/accounts/124 in a request, and the API happily returns someone else’s account data because it checked that a valid user was logged in, but never checked which objects that specific user was allowed to see.

A related but distinct risk, Broken Function Level Authorization (BFLA), is the same failure at a different layer: an endpoint intended for admin users that a standard authenticated user can reach directly, because the authorization check that should gate it was never actually enforced server-side.

The Fuller Checklist

Beyond object and function-level authorization, a structured API security review needs to cover:

• Authentication and session management — is the JWT or OAuth implementation actually correct, not just present? Token expiry, signature verification, and refresh token handling are common places this goes wrong.
• Excessive data exposure — does an endpoint return an entire object (including fields the client never uses and shouldn’t see) because it was simpler to build than a properly filtered response?
• Rate limiting and resource abuse — can an endpoint be hit fast enough to enable brute-force attacks, scraping, or denial-of-service, or is there no meaningful limit in place at all?
• Injection vulnerabilities — the same category of risk as in traditional web applications, applied to every parameter an API endpoint accepts, not just the obvious ones.
• Security misconfiguration — verbose error messages leaking stack traces, debug endpoints left enabled, overly permissive CORS policies.
• Business logic bypasses — flows that are only exploitable by understanding what the API is for, not just how it’s built: a discount code endpoint that doesn’t validate order totals server-side, a checkout flow that trusts a client-supplied price.

For GraphQL APIs specifically, add: schema introspection exposure (an unauthenticated client requesting your entire schema and getting it), nested query denial-of-service (a deliberately deep or wide query designed to exhaust server resources), and batching abuse (using GraphQL’s batching feature to work around rate limits that were designed for one request at a time).

What a Structured Test Actually Covers

Testing this properly starts with API discovery and mapping — enumerating every endpoint, parameter, authentication mechanism, and data flow, using both documentation and active discovery, because undocumented endpoints are common and are exactly the ones nobody thought to secure carefully. Authentication and authorization testing follows: the JWT/OAuth implementation, session management, and systematic BOLA/BFLA testing across every user role the API supports, not just the standard user case. Business logic and injection testing comes next — data exposure, rate limiting bypass, and the application-specific flows a generic scanner has no way to understand. The engagement closes with a structured, CVSS-scored report: endpoint-specific findings, working exploit proofs, and remediation code specific to the API framework in use.

What This Catches in Practice

An Open Banking API serving 15 mobile applications and 3 enterprise integrations had never had BOLA testing performed — the only security review the API had received was documentation review. A structured penetration test found BOLA on 6 endpoints, allowing access to any user’s transaction history and account details, plus broken function-level authorization on admin endpoints that were reachable without an admin role at all. Every critical finding was remediated before public launch, the OAuth2 PKCE implementation was reviewed and approved by the security team, and the API has had zero post-launch security incidents since.

The uncomfortable detail in that case study: documentation review alone found nothing. The vulnerabilities were only visible to someone actually sending requests and checking whether the authorization logic held up — which is what structured API security testing is for.