8 API Vulnerabilities Standard Penetration Tests Miss

APIs are now the primary attack surface of most web applications. Gartner predicted API attacks would become the most frequent attack vector for enterprise web applications by 2022, and that prediction proved accurate. Despite this shift, most penetration testing methodologies have not caught up.

Standard web application pentests were designed around page-based, form-driven applications. The testing methodology, the tools, and the mental model all assume HTTP request-response cycles with HTML rendered in a browser. When those same tests are applied to modern API-first applications, REST backends, GraphQL endpoints, and microservice architectures, significant portions of the attack surface go untested by default.

This is not a criticism of the testers. It is a structural gap in what standard methodology covers when applied to an architecture it was not designed to test. These eight API vulnerability classes are the ones that fall outside standard pentest coverage most consistently.

1. Mass assignment vulnerabilities

Mass assignment occurs when an API accepts object properties from client input without explicitly specifying which fields are permitted to be set. The vulnerability allows an attacker to supply additional parameters that the application applies without validation.

The classic example is a user registration endpoint that accepts {"name": "Alice", "email": "alice@example.com"} but also processes {"name": "Alice", "email": "alice@example.com", "role": "admin", "verified": true} without error. If the application maps the request body directly to a user object, the attacker has just self-assigned administrative privileges.

Standard pentests test the parameters they see in API documentation or proxied traffic. Mass assignment requires testing parameters that are not documented and do not appear in normal application flow: internal fields, audit flags, permission attributes, and account state fields that exist in the data model but are intended to be set only server-side. Finding these requires understanding the application's object model rather than just observing its documented interface.

2. Broken function level authorization

Function-level authorization flaws occur when an API exposes endpoints that should be restricted to certain roles or user types without actually enforcing those restrictions.

The most common pattern is an administrative API layer that is not linked from the application interface but is accessible by any authenticated user who knows or can guess the endpoint path. API versioning makes this worse: an application may have deprecated an administrative endpoint in v2 but left the v1 version accessible and unenforced.

Standard pentests focus on the endpoints that surface through normal application use. Broken function level authorization requires enumerating undocumented endpoints, testing HTTP methods that documentation does not mention (whether a read-only endpoint responds to PUT or DELETE), probing version paths that are not current, and testing whether endpoints that require elevated privileges in one context enforce those privileges consistently in all contexts.

This is the API-specific form of the broader authorization gap that is the most common finding in real penetration test engagements. As covered in the detailed breakdown of the security gaps DAST and standard scanning miss, authorization flaws across authenticated surfaces are consistently the highest-impact findings and the ones automated tools are least equipped to find.

3. GraphQL-specific attack vectors

GraphQL presents an attack surface that is fundamentally different from REST, and standard REST-focused pentest methodology covers it poorly.

Introspection queries expose the complete data schema when not disabled: every type, field, mutation, and query the API supports becomes visible to anyone who can reach the endpoint. Attackers use introspection to discover data relationships and fields that are not exposed through the application interface but may be accessible through direct API queries.

Deeply nested queries enable resource exhaustion through query complexity: a query that retrieves authors, each with books, each with reviews, each with reviewers, each with their authored books can generate exponential database load that no rate limiter applied at the HTTP layer will prevent. Batching attacks send multiple operations in a single request to bypass per-request rate limits. Field-level authorization inconsistency is common where a resolver enforces access control for one data path but exposes the same underlying data through a different query path without the same check.

Standard pentests that apply web application scanning tools to GraphQL endpoints catch generic injection classes but miss the schema-specific attack surface entirely. Thorough GraphQL testing requires introspection analysis, query complexity testing, batching abuse, and systematic comparison of authorization enforcement across all resolver paths that reach the same underlying data.

4. JWT implementation flaws beyond algorithm confusion

JWT vulnerabilities are commonly known in theory but frequently undertested in practice. Standard methodology checks for the "none" algorithm attack, which is well-documented and often caught. The more subtle implementation flaws are missed.

Weak signing secrets are testable offline. When a valid JWT is captured, the signing secret can be attempted against common wordlists and computational attacks without interacting with the application. If the secret is short or drawn from a common pattern, the JWT can be forged, allowing arbitrary claim manipulation without detection. This requires offline tooling and wordlist testing that is not part of standard proxy-based API assessment.

Key confusion attacks exploit applications that accept multiple signing algorithms. When an application that uses RS256 (asymmetric) also accepts HS256 (symmetric), an attacker can take the application's public key and use it as the symmetric secret, signing a forged token that the application validates successfully. Testing this requires attempting signature verification with the public key as the HMAC secret, which requires deliberate test-case construction beyond standard scanning.

Token lifetime and invalidation testing is frequently skipped in time-bounded engagements: whether logout actually invalidates the token server-side, whether tokens issued before a password reset remain valid after the reset, and whether tokens with elevated claims can be replayed after the privilege is revoked.

5. API rate limiting and business logic abuse

Rate limiting vulnerabilities in APIs are distinct from the rate limiting tests applied to login forms in standard web application pentests.

API rate limiting is typically implemented at the HTTP layer and counts requests per IP, per token, or per account. Each of these can be bypassed through different mechanisms. Per-IP limits are bypassed by rotating source addresses or by using the application's own SSRF vulnerabilities to proxy requests. Per-token limits are bypassed by creating multiple accounts or by exploiting token sharing patterns in the API's own documentation. Per-account limits can sometimes be bypassed by manipulating account identifiers in the request or by using concurrent requests that all clear the rate check before any of them update the counter.

Business logic rate limit abuse is more specific: exploiting the race condition in coupon redemption that allows two simultaneous requests to both pass the "has this been used?" check, applying a discount code across multiple orders by manipulating the association between code and order before the application marks the code as consumed, and transferring balances or credits faster than account state updates can track.

6. Server-side request forgery through API parameters

SSRF in API-driven applications presents differently from SSRF in traditional web applications and is missed by standard testing approaches that look for SSRF in browser-facing URL fields.

Modern APIs frequently accept URLs as parameters for legitimate functionality: webhook configuration endpoints that tell the application where to send event notifications, document import features that fetch content from a supplied URL, image processing endpoints that accept a source URL, and integration configuration screens where administrators supply external service endpoints.

Each of these is a potential SSRF vector. Testing requires identifying every parameter that causes the application to make a server-side HTTP request, then testing those parameters against internal targets including cloud metadata endpoints, internal network ranges, and localhost services. Blind SSRF, where the application makes the request but does not return the response to the client, requires out-of-band detection and is missed entirely by scanners that rely on observing response differences.

In cloud-hosted APIs, SSRF against cloud metadata services (169.254.169.254 for AWS) provides access to instance credentials that can be used for lateral movement into the broader cloud environment. This is among the highest-impact API vulnerability classes and among the most consistently undertested. The contrast with a more thorough approach is covered in the comparison of what agentic AI pentesting finds that standard DAST misses.

7. Insecure API versioning and deprecated endpoint exposure

API versioning creates a specific attack surface that does not exist in traditional web applications. When APIs evolve through version increments (v1, v2, v3), older versions are frequently maintained for backward compatibility without the same security controls applied to current versions.

The pattern is consistent: a security fix applied to the current API version is not backported to deprecated versions. An authorization requirement added in v2 does not apply to the v1 endpoint that still exists. A rate limit added in v3 is not present on the v1 equivalent. The documented, current API surface is tested; the version history is not.

Testing API versioning exposure requires probing the full version namespace beyond what documentation reveals, testing whether security controls applied in current versions are consistently enforced in older ones, and checking whether deprecated endpoints documented as retired are actually removed or merely undocumented.

8. WebSocket and asynchronous message security

WebSocket connections are increasingly used in modern applications for real-time features: live chat, collaborative editing, real-time data feeds, and event-driven notifications. Standard web application pentest methodology handles WebSockets poorly because they operate on a different model from the HTTP request-response pattern that proxy-based testing is designed around.

WebSocket vulnerabilities that standard testing misses include: authentication enforcement on the WebSocket upgrade request and on individual message types after the connection is established (a WebSocket that authenticates the initial connection but does not re-validate authentication on privileged message types is vulnerable to session takeover through connection reuse), authorization checks on WebSocket messages (whether message types that trigger privileged actions validate the sender's permission to trigger them), injection vulnerabilities in WebSocket message payloads (SQL injection, command injection, and stored XSS are all possible in data processed from WebSocket messages), and cross-site WebSocket hijacking when the upgrade request does not validate the Origin header.

Testing these requires a methodology that treats WebSocket traffic as a distinct message-passing protocol rather than as a variant of HTTP, which most proxy-based web application testing tools do not do natively.

Why standard pentests miss these categories

The common thread across all eight is the same: standard web application penetration testing methodology was built around HTTP request-response cycles, form-based input, and page-rendered output. When applied to REST APIs it covers a reasonable subset of the attack surface. When applied to GraphQL, WebSocket, gRPC, or event-driven architectures it covers much less. When it requires reasoning about data models, version history, or asynchronous message patterns, it misses more still.

Closing these gaps requires a testing approach that understands the specific architecture being tested, adapts methodology to the API type encountered, and systematically covers the authorization, versioning, and protocol-specific vulnerability classes that standard tooling does not reach.

Agentic pentesting covers all eight categories above. Each 10x Pentest agent is specialized for specific vulnerability domains and applies the appropriate methodology to the architecture it encounters, whether that is a REST API with JWT authentication, a GraphQL endpoint requiring schema introspection, or a WebSocket connection requiring message-level authorization testing. See how the 10x Pentest platform is structured across its agent architecture, or review pricing for continuous API security coverage. For teams evaluating what genuine API penetration testing covers versus what standard web application testing provides, the overview of web application penetration testing: what a real engagement should cover maps the full scope.

For teams ready to move from periodic standard pentests to continuous, architecture-aware API security validation, the 10x Pentest team can assess current API coverage gaps and map what a shift to continuous agentic testing would cover across your specific stack.

Frequently asked questions

1. What is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a regularly updated list of the most critical API security risks, maintained by the Open Web Application Security Project. The current edition covers broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs. It is the foundational reference for API security testing and provides a structured framework, though thorough API testing goes beyond the list to cover architecture-specific vulnerabilities like the eight categories in this post.

2. What is the difference between API security testing and web application penetration testing?

Web application penetration testing was designed for browser-rendered applications with form-based interfaces. API security testing addresses the distinct attack surface of programmatic interfaces: REST endpoints, GraphQL schemas, WebSocket connections, and service-to-service communication layers. The vulnerability classes overlap in some areas (injection, authentication) and diverge significantly in others (mass assignment, GraphQL batching attacks, JWT algorithm confusion, version exposure). Modern applications typically require both, because the API layer and the web interface often have different authentication models, different authorization enforcement, and different exposure to the vulnerability classes each testing approach covers.

3. How often should API penetration testing be done?

For APIs that serve production traffic and change frequently, continuous is the right answer. The argument for continuous testing is strongest for APIs: they change more frequently than web interfaces (new endpoints, new parameters, new versions), they are often less visible than web interfaces (not linked from a sitemap, not directly browsable), and they carry higher-impact data in most modern applications. At minimum, API security testing should trigger on every significant deployment that changes API behavior, not run on a fixed calendar schedule independent of when the API actually changes.

4. Can automated scanners find API vulnerabilities?

Automated scanners find a subset of API vulnerabilities reliably: known injection classes in accessible parameters, missing security headers, and some authentication configuration issues. They miss the eight categories in this post because those vulnerabilities require reasoning about the application's data model, version history, authorization logic, and protocol-specific behavior rather than matching observed responses against a signature library. Mass assignment requires probing undocumented parameters. Broken function level authorization requires testing undocumented endpoints. GraphQL vulnerabilities require schema analysis. WebSocket authorization requires message-level testing. These are not scanner-discoverable through payload matching.

5. What tools are used for API penetration testing?

API penetration testing uses a combination of tools depending on the API type. Burp Suite and OWASP ZAP are the standard intercepting proxies for REST API testing, capturing and manipulating HTTP traffic. Postman is used for structured API exploration and request replay. GraphQL-specific tools like InQL and Clairvoyance handle introspection and schema exploration. JWT analysis tools like jwt_tool test token implementation weaknesses including offline secret cracking and algorithm confusion attacks. Agentic pentesting platforms apply all of these methodologies automatically and continuously, adapting the approach to the API architecture encountered rather than requiring manual tool selection and configuration for each engagement.