API Penetration Testing: OWASP Top 10 Guide

API penetration testing is a targeted adversarial assessment of the HTTP endpoints modern applications use to communicate — REST, GraphQL, and SOAP interfaces that automated scanners routinely miss. Salt Security's 2023 State of API Security report found that 94% of organizations experienced API security incidents in the prior twelve months, and Gartner identifies APIs as the most frequent attack vector for web breaches. A mid-size SaaS product commonly exposes hundreds of API endpoints across multiple versions.

Standard DAST tools are insufficient for API security assessment: the majority of high-severity API vulnerabilities — broken object-level authorization, excessive data exposure, function-level authorization flaws — require manual, authenticated testing to detect. The OWASP web application penetration testing methodology provides the complementary framework for the web layer that typically sits in front of these APIs.

This guide covers what professional API penetration testing actually looks like — from the OWASP API Security Top 10 (2023 edition) to testing differences across REST, GraphQL, and SOAP, to the tooling and authentication testing techniques that matter most.

OWASP API Security Top 10 (2023): The Current Threat Landscape

OWASP published the updated API Security Top 10 in 2023, refining the 2019 list based on documented breach patterns and expanded contributor data. Every finding in this list corresponds to real-world exploits, not theoretical risk.

API1:2023 — Broken Object Level Authorization (BOLA)

The single most critical API vulnerability category. BOLA occurs when an API endpoint accepts a user-supplied identifier (e.g., /api/orders/{orderId}) and returns data for that object without verifying that the requesting user is authorized to access it. An attacker who can access their own orderId=1001 can trivially try 1000, 999, and so on — often with zero indication that enumeration is being detected. This is the root cause of numerous high-profile API data breaches.

Testing involves systematically substituting identifiers across all object-level endpoints, testing both numeric sequences and UUIDs, and attempting access with different authentication contexts.

API2:2023 — Broken Authentication

Weak API authentication mechanisms: API keys transmitted in URLs (logged in server logs and browser history), absence of token expiry, non-revocable tokens, weak JWT secrets, missing signature validation on JWTs, and OAuth flows with insufficient state validation. Unlike web application authentication testing, API authentication often involves dozens of different token types and grant flows across the same application.

API3:2023 — Broken Object Property Level Authorization (BOPLA)

New in 2023, this consolidates the former "Excessive Data Exposure" and "Mass Assignment" entries. BOPLA covers two distinct failure modes: APIs returning more properties than the consumer should see (leaking isAdmin, internalCreditScore, rawPasswordHash), and APIs accepting more properties than they should on write operations (allowing a client to set role: admin in a POST body).

API4:2023 — Unrestricted Resource Consumption

Previously "Lack of Resources & Rate Limiting." APIs that do not enforce limits on request rate, payload size, query complexity, or execution time are vulnerable to denial-of-service and to enumeration attacks that rely on making thousands of requests. GraphQL APIs are especially susceptible here — deeply nested queries can consume exponential server resources.

API5:2023 — Broken Function Level Authorization (BFLA)

Where BOLA is about accessing the wrong object, BFLA is about accessing the wrong function — calling administrative endpoints, invoking privileged operations, or using HTTP methods (DELETE, PUT, PATCH) on endpoints that should be read-only for the requesting role. Testing requires mapping every API function and verifying that authorization is enforced at the function level, not just the object level.

API6:2023 — Unrestricted Access to Sensitive Business Flows

New in 2023, this category addresses APIs that properly authenticate and authorize requests but expose business flows that can be abused at scale — bulk price scrapers, credential stuffing via login APIs, gift card enumeration, and ticket scalping automation. The vulnerability is not a technical flaw but a missing abuse-rate control.

API7:2023 — Server Side Request Forgery (SSRF)

APIs that accept URLs or host parameters and make server-side requests on behalf of the client are vulnerable to SSRF. The consequences in cloud environments are severe: accessing AWS EC2 metadata at 169.254.169.254/latest/meta-data/iam/security-credentials/ can yield temporary IAM credentials with significant cloud-account privileges.

API8:2023 — Security Misconfiguration

The API equivalent of OWASP Top 10's A05: default credentials on API gateways, missing TLS, permissive CORS headers (Access-Control-Allow-Origin: * on authenticated endpoints), verbose error responses exposing stack traces and internal paths, and unnecessary HTTP methods enabled.

API9:2023 — Improper Inventory Management

Organizations routinely lose track of which API versions are deployed in production. An API that was deprecated but never decommissioned — running an older version with known vulnerabilities, without rate limiting, and without current authentication requirements — is a standing invitation for exploitation. Testing requires discovering all deployed API versions, not just the current one.

API10:2023 — Unsafe Consumption of APIs

The inverse risk: the application under test itself consumes third-party APIs, and the way it processes those responses creates vulnerabilities. Insufficient validation of data returned from external APIs, blind trust in third-party responses, and SSRF through API aggregation flows all belong here.

REST vs. GraphQL vs. SOAP: Testing Differences That Matter

REST APIs

The most common API style. Testing focuses on parameter manipulation across URL paths, query strings, and request bodies; HTTP verb coverage; authentication header analysis; and response body inspection for data leakage. Swagger/OpenAPI specifications, when available, provide a complete map of declared endpoints — but undocumented endpoints (shadow APIs) often exist alongside the specification and must be discovered independently.

GraphQL APIs

GraphQL introduces a fundamentally different attack surface. A single endpoint (/graphql) accepts arbitrary query structures, and the authorization model must be enforced at the resolver level for every field — a single misconfigured resolver can expose the entire data model.

Key GraphQL-specific tests:

Introspection — is schema introspection enabled in production? If so, the full type system and every available query is disclosed to any requester.
Query depth and complexity limits — unbounded nested queries can exhaust server resources. Test with deeply recursive queries.
Batch query abuse — GraphQL allows multiple operations in a single request, which can be used to bypass rate limiting.
BOLA via GraphQL arguments — every ID-accepting field is a potential object-level authorization bypass.

SOAP/XML APIs

Older but still prevalent in financial services, healthcare, and enterprise integrations. SOAP testing covers XML injection, XXE (XML External Entity) injection — which can achieve file read and SSRF through malicious DOCTYPE declarations — WSDL enumeration for exposed operations, and WS-Security header manipulation.

Authentication Testing: JWT, OAuth 2.0, and API Keys

JWT (JSON Web Tokens)

JWTs are the dominant authentication mechanism for REST APIs. Common JWT vulnerabilities:

Algorithm confusion attacks — changing the alg header from RS256 to HS256, then signing with the public key as the HMAC secret
alg: none attacks — some libraries accept unsigned tokens if the algorithm is set to none
Weak secret brute-forcing — HMAC-signed JWTs with weak secrets can be cracked offline using hashcat or jwt-cracker
Missing exp claim validation — expired tokens accepted indefinitely
kid header injection — SQL injection or path traversal through the kid (Key ID) header in libraries that use it to look up the signing key

OAuth 2.0

OAuth flows introduce multiple attack surfaces: authorization code interception (missing PKCE), state parameter CSRF bypasses, open redirect abuse to steal authorization codes, token leakage via Referrer headers, and scope elevation through misconfigured consent screens.

API Keys

API keys are simple but frequently mishandled: keys embedded in JavaScript bundles, committed to public repositories, transmitted in query parameters (logged by CDNs and proxies), and issued without expiry or rotation policy. Testing covers both the transmission security and the scope/privilege associated with discovered keys.

Tooling

Tool	Role
Burp Suite Pro	Full request/response interception, scanner, active testing
Postman / Insomnia	Collection-based API testing, environment variable management
OWASP ZAP	API scanning via OpenAPI/Swagger import, fuzz testing
jwt-tool	JWT manipulation, algorithm confusion, brute-force
GraphQL Voyager / InQL	GraphQL schema visualization, introspection extraction
ffuf	Endpoint discovery, parameter fuzzing
Nuclei	Templated CVE scanning across API endpoints
kiterunner	API-specific wordlist-based endpoint discovery

Real-World Use Case: BOLA in a Healthcare API

BOLA is frequently described in the abstract, but understanding how it manifests in production helps security teams recognize the conditions that create it. The following scenario is representative of findings documented in published security assessments of telehealth platforms.

A telehealth provider exposes a REST API for patient appointment management. The API authenticates users via JWT and appears secure from a network scanner perspective: all endpoints use HTTPS, rate limiting is configured, and JWT signatures are valid. During a penetration test, the tester authenticates as a standard patient user and begins examining appointment-related endpoints. The appointments resource follows a predictable pattern: GET /api/v1/appointments/{appointmentId}.

By iterating appointment IDs from 10000 to 10050 while authenticated as Patient A, the tester retrieves appointment records belonging to 50 different patients — including full names, protected health information (PHI), treating physician notes, and scheduled procedure details. No error is returned. No rate limiting triggers. No authorization check fires at the object level.

The root cause is a single architectural decision: authorization was enforced at the endpoint level (is this user authenticated?) but not at the object level (is this user authorized to see this appointment?). The application verified that a valid JWT was present and that the user had the patient role. It did not verify that the patientId embedded in the appointment record matched the sub claim in the token.

This is a textbook BOLA finding. It is the most commonly reported critical vulnerability in healthcare API assessments and among the most likely API flaws to trigger HIPAA breach notification obligations, since it involves unauthorized access to PHI at scale. The fix — a single server-side ownership check before returning the record — is straightforward. The damage from leaving it undetected is not.

Common API Security Mistakes to Avoid

Even teams that follow secure development practices tend to reproduce a predictable set of API-specific errors. Understanding these patterns helps both developers and security reviewers know where to focus attention.

Trusting the API gateway for all authorization — API gateways are excellent at enforcing rate limiting, validating authentication tokens, and routing traffic. They are not designed to enforce object-level or function-level authorization, because those decisions require application context the gateway does not have. Authorization logic must live in the application code itself, not in the infrastructure layer in front of it.

Exposing internal microservice APIs without authentication — service-to-service APIs that assume they will only be called from trusted internal services frequently have no authentication controls at all. A single SSRF vulnerability in any external-facing component, or a single compromised container in a Kubernetes cluster, can expose the entire internal API mesh to an attacker who now has unauthenticated access to every downstream service.

Returning verbose error messages — stack traces, SQL query fragments, ORM error text, and internal server file paths in API error responses are reconnaissance assets for an attacker. They disclose the technology stack, the database schema, and the internal directory structure. Structured error responses that return a generic error code to the client — while logging detail internally — eliminate this exposure.

Not versioning with security in mind — v1 endpoints that were deprecated when v2 launched but never actually decommissioned are a recurring source of critical findings. Older API versions frequently have weaker authentication requirements, no rate limiting, and known unpatched vulnerabilities. Attackers routinely discover them through path enumeration with tools like kiterunner and ffuf. The deprecation calendar must include a hard sunset date and a decommission verification step.

Mass assignment in ORM-backed endpoints — web frameworks that automatically bind HTTP request body properties to model fields allow clients to set properties that were never intended to be user-controllable. A PATCH endpoint designed to update a user's display name can become a privilege escalation vector if the framework binds isAdmin, internalScore, or billingOverride from the request body to the model. Explicit allowlists — not denylists — of bindable properties prevent this class of vulnerability.

What API Testing Scope Should Include

A properly scoped API pentest defines:

Base URLs and version prefixes for all API surfaces (v1, v2, internal, partner)
Authentication credentials at every role level
API specification files (OpenAPI, Swagger, WSDL, GraphQL schema) — plus explicit acknowledgment that shadow endpoints outside the spec are in scope
Rate limiting policies currently in place (so testers can assess their effectiveness without triggering production incidents)
Mobile application binary access if the API is consumed by a mobile client — the mobile app penetration testing guide covers how client-side secrets, hardcoded endpoints, and certificate pinning configuration are discoverable from the binary

A well-scoped API penetration test covers not just the declared endpoints in an OpenAPI specification but also shadow APIs, undocumented internal routes, and every authentication flow in use. The authorization flaws that matter most — particularly BOLA and BFLA — require a tester who understands the application's data model well enough to probe access control decisions at the object and function level, not just run automated scans.

WhiteJaguars is one provider that focuses specifically on this class of manual authorization testing across REST, GraphQL, and SOAP architectures.

Frequently Asked Questions

Is API penetration testing different from web application penetration testing?

Yes, in several important ways. Web application penetration testing focuses on the browser-facing layer: HTML rendering, session cookies, CSRF, DOM-based XSS, and server-side injection through form fields. API penetration testing focuses on the data exchange layer: authentication tokens, object-level authorization, data exposure in JSON/XML responses, and protocol-specific flaws in REST, GraphQL, or SOAP. The two disciplines share some techniques — injection testing, authentication analysis, and session management review overlap — but the tooling, the attack surface enumeration approach, and the most critical vulnerability categories differ substantially. Many production applications require both assessments: a web application test for the browser interface and a dedicated API test for the endpoints it calls. Running only one misses the attack surface addressed by the other.

How should I provide API credentials to the testing team?

Provide test accounts at every privilege level that exists in the application: standard user, privileged user, administrative user, and any service or partner roles. These should be dedicated test credentials created for the engagement — not production user accounts — so the testing team can make arbitrary requests, modify data in test environments, and enumerate objects without affecting real users. Include the credential format: whether authentication uses bearer tokens, API keys, client certificate mutual TLS, or a combination. If the API uses OAuth 2.0, provide client credentials and document the authorization flows in scope. For APIs that use rotating tokens or short-lived JWTs, provide the mechanism to generate new tokens during the test — not a single token that may expire mid-engagement. Credentials should be transmitted to the testing team through an encrypted channel, never in plaintext email.

Does API penetration testing cover mobile app APIs?

An API penetration test scopes the server-side API endpoints directly — it does not include analysis of the mobile application binary itself. However, the two assessments are closely related. Mobile applications are a common discovery mechanism for undocumented API endpoints: static analysis of a mobile binary frequently reveals hardcoded base URLs, endpoint paths, API keys, and certificate pinning configurations that are not in any published specification. If the API under test is consumed by a mobile client, the most thorough approach combines both assessments. The mobile app penetration testing guide covers the binary analysis techniques that surface these findings. Organizations running API-first mobile products should treat mobile and API testing as a single coordinated engagement rather than two separate scopes.

How long does an API penetration test typically take?

Duration depends primarily on the number of endpoints, the number of distinct authentication roles, and the complexity of the business logic. A focused API assessment covering a single microservice with 20–30 endpoints and two or three roles typically takes three to five business days. A comprehensive assessment of a platform API with hundreds of endpoints across multiple versions, several privilege levels, and complex OAuth flows can take two to three weeks. The scoping phase — reviewing OpenAPI specifications, understanding the data model, and mapping the authorization logic — is not overhead; it is what allows a tester to craft meaningful object-level authorization tests rather than generic fuzzing. Unrealistic timelines that compress this phase consistently produce lower-quality findings, particularly for BOLA and BFLA, which require semantic understanding of the application to test effectively.

What documentation should I prepare before an API test begins?

The most useful documentation to provide before an API penetration test includes: OpenAPI, Swagger, or WSDL specification files for all API versions in scope; a data model or entity relationship overview describing the primary objects the API manages and how they relate to each other; an authentication and authorization summary explaining which roles exist, what each role can access, and how tokens are issued and validated; a list of all deployed API versions and the base URLs for each environment in scope; and any known shadow endpoints or undocumented internal routes. If the API has previously undergone security assessment, the prior findings report helps the testing team understand what has already been remediated and where historical weaknesses existed. The more complete this documentation at the start of the engagement, the more time the testing team can spend on manual authorization testing and business logic review rather than basic reconnaissance.

API Penetration Testing: Risks, Tools & Methodology Guide