A Taxonomy of API Attack Vectors and Hardening Responses

Not all API attacks are the same, and applying the wrong control to the wrong vector wastes budget and leaves you exposed. This taxonomy organizes API-layer attack vectors into four classes based on what resource they exhaust and how the attacker achieves amplification. Each class maps to a distinct set of defensive controls.

The classification matters for prioritization. A compute-exhaustion attack through expensive database queries requires a different response than a connection-exhaustion attack through TLS handshake floods. Conflating them leads to over-investment in CDN capacity while the origin remains unprotected, or the reverse: strict IP rate limiting that stops credential stuffing but misses per-session abuse from legitimate-looking clients.

Class 1: Compute Exhaustion via Expensive Operations

The attacker identifies endpoints whose server-side processing cost is disproportionate to the request size. Typical examples: full-text search with complex filters, report generation that joins multiple tables, GraphQL queries with high nesting depth, or bulk export endpoints with no pagination enforcement. A 200-byte request can trigger 50ms of CPU and multiple database round-trips. At 500 requests per second from a small botnet, this saturates a moderately sized origin.

Hardening response: Per-endpoint rate limits calibrated to the processing cost of each endpoint, not a single global rate. Query timeout enforcement at both the application layer and the database layer. GraphQL depth and complexity limits. Pagination requirements on all list endpoints with a hard maximum page size.

Class 2: Connection Exhaustion

The attacker holds open large numbers of connections at various stages: TLS handshake incomplete, HTTP request headers partial, or keep-alive connections idle. Each incomplete connection consumes a file descriptor and memory in the connection table. At scale, the server stops accepting new connections from legitimate users before a single request is processed.

Hardening response: TLS handshake timeout (typically 10 seconds; many servers default to 60 or unlimited). HTTP request header timeout. Maximum connections per IP at the edge, not just at the origin. Idle connection timeout set explicitly rather than relying on OS defaults, which are frequently 7200 seconds.

Class 3: Credential and Session Abuse

Authentication endpoints are targeted by credential stuffing, password spraying, and OTP exhaustion. The attack is DDoS-equivalent when the rate exceeds the origin's capacity to hash passwords and validate sessions. Because each request is a legitimate-format HTTP POST with valid JSON structure, WAF signature rules do not fire. The load is indistinguishable from a user traffic spike until the error rate rises.

Hardening response: Per-IP rate limit on auth endpoints at 5-10 requests per minute. Per-username rate limit (independent of IP, to counter distributed credential stuffing). CAPTCHA or proof-of-work challenge after first failed attempt per IP. Monitoring on the ratio of failed to successful auth attempts per 5-minute window, with alerting when it crosses 10:1.

Class 4: Amplification via Response Size

The attacker sends small requests to endpoints that return large responses: unbounded list queries, verbose error pages with full stack traces, or endpoints that serialize deeply nested object graphs. The attack goal is bandwidth exhaustion of the origin-to-CDN or origin-to-client link. A 100-byte request returning a 2MB response gives the attacker a 20,000x amplification factor using your own infrastructure.

Hardening response: Maximum response size limit at the proxy layer. Mandatory pagination with hard maximum. Error response sanitization -- stack traces and internal paths stripped before response reaches the client. Separate rate limits on high-bandwidth endpoints regardless of per-IP limits on standard endpoints.