Hardening an API at a single layer creates a false sense of coverage. A WAF rule that blocks high-rate IPs does nothing against a distributed botnet. An API gateway timeout that protects the origin does nothing if the gateway itself is saturated. Effective API hardening requires controls at each layer of the request path, each addressing the failure modes the layer above cannot handle.
DDactic assessments regularly find organizations that have invested heavily in one layer -- typically the CDN or WAF -- while leaving the API gateway, origin web server, and application code without any rate controls. When an attacker bypasses or saturates the primary defense, there is nothing behind it. This post maps the control surface at each layer and the specific configurations that matter.
Layer 1: CDN Edge
The CDN edge is the first point of contact for most API traffic. Controls at this layer operate before traffic touches your infrastructure. The primary CDN-level controls for API hardening are: IP reputation filtering (blocking known-bad ASNs and datacenter ranges for endpoints that have no legitimate machine-client traffic), geo-restriction for endpoints that only serve a specific region, and connection-rate limiting at the TCP level. CDN caching is irrelevant for authenticated APIs, but some CDNs support request coalescing -- collapsing multiple identical unauthenticated requests into one upstream call -- which helps for public read endpoints.
The gap at this layer: CDN edge controls cannot inspect application state. They cannot know that a request is for an account with a free-tier limit, or that the requesting user has already triggered a circuit breaker. They are coarse controls, effective against volumetric threats but blind to application-semantic abuse.
Layer 2: WAF
The WAF layer adds HTTP request inspection: path-based rate limiting, header validation, payload size limits, and signature-based blocking. Rate limits at this layer should be per endpoint path, not global, because different endpoints have different legitimate traffic profiles and different backend computation costs. A search endpoint that can handle 50 requests per second before the database saturates should have a rate limit of 50 rps, regardless of what the global WAF policy allows.
WAF rate limit granularity
Set WAF rate limits at the most specific path that covers a cost class. If /api/v2/search and /api/v2/export both hit the same expensive query, they should each have their own limit, not share a combined limit on /api/v2/.
Layer 3: API Gateway
The API gateway is the first layer with application context: it knows which API key or user token is making the request, what plan the user is on, and what their current usage looks like. Rate limiting here should be plan-aware -- free tier users get 100 requests per minute, paid users get 10,000. Circuit breakers at the gateway level protect the origin from cascading failures: when the upstream response time exceeds a threshold, the gateway returns 503 immediately rather than queuing more requests that will also time out.
Layer 4: Origin Web Server
The origin server is the last hardware defense before application code. Connection limits (LimitRequestBody in Apache, client_max_body_size in Nginx), request timeouts, and connection pool limits prevent a flood that reaches the origin from exhausting OS resources. These settings are often left at their defaults -- which are designed for development convenience, not production resilience. A default Nginx configuration allows 1024 worker connections with no per-IP limit and a 60-second keepalive timeout. Under load, this configuration will accept and hold open thousands of idle connections from a slow-read attack.
Layer 5: Application Code
The application layer controls what happens when a request passes all outer layers. Database query timeouts, pagination enforcement, and async job queuing for expensive operations prevent single requests from monopolizing resources. The most impactful application-level protection is a hard timeout on every external call -- database, cache, third-party API -- combined with a circuit breaker that stops calling a degraded downstream service. Without these controls, a single slow database query can cascade into a full application hang by exhausting the thread pool while threads wait for query results that never arrive.
Do not rely on upstream layers to substitute for application timeouts
A WAF timeout of 30 seconds does not protect you if the application has no query timeout. The WAF will close the connection at 30s, but the database query will continue running, holding locks and consuming resources, until it completes or times out at the database level.
Map Your API Defense Layers
DDactic scans each layer of your API stack and identifies where defenses are missing or misconfigured. The result is a prioritized hardening list, not a generic checklist.
Run a Free Scan