A blanket rate limit of 1,000 requests per minute applied to all API paths is simultaneously too permissive for expensive endpoints and too restrictive for cheap ones. The organization believes it has rate limiting configured. An attacker targeting the search endpoint at 999 requests per minute finds no resistance. A legitimate monitoring system polling a status endpoint at 1,001 requests per minute gets blocked. The configuration provides false coverage while creating operational friction.
DDactic consistently identifies blanket WAF configurations as one of the most common findings in assessments of organizations with mature security programs. The WAF is configured, the dashboard shows rules are active, but the rules are not calibrated to the actual cost profile of individual endpoints. A single high-cost endpoint can be saturated at rates the blanket rule never triggers on.
The Cost Profile Divergence Problem
API endpoints in a typical application have computation costs that span three to four orders of magnitude. A health check endpoint (GET /ping) returns in under 1ms and costs essentially nothing. A search endpoint with full-text indexing across millions of records may take 500ms and hold a database connection for that duration. An export endpoint generating a CSV or PDF may run for 30 seconds and consume significant CPU. Applying a single rate limit across all three is incoherent: the limit that protects the export endpoint from saturation will block legitimate usage of the health check endpoint, and the limit appropriate for the health check provides no protection for the export endpoint.
How Attackers Exploit Blanket Configurations
Attackers do not send uniform traffic. They probe an application's endpoints to identify which are computationally expensive and which rate limits apply to which paths. A blanket rate limit is easy to probe: send requests to the target endpoint at increasing rates until a 429 response appears, then back off to just below that rate. If the same rate limit applies to a cheap endpoint and an expensive one, the attacker targets the expensive one at just below the blanket limit and achieves resource exhaustion that the blanket rule was designed to prevent.
The False-Coverage Pattern
Blanket configurations create a specific organizational failure mode: security teams believe they are protected because a rate limit rule exists and is active. This belief survives audit because the rule is visible in the WAF dashboard and applies to the relevant paths. The gap is not visible without measuring actual saturation thresholds per endpoint -- which most security tools do not do. The WAF vendor's documentation does not warn you that your blanket limit is too permissive for endpoint X; it simply executes the rule you configured.
WAF rule existence is not the same as WAF rule effectiveness
A WAF rule that fires at 1,000 rps does not protect an endpoint that saturates at 50 rps. The finding to look for is not "does a rate limit exist" but "does the rate limit fire before the endpoint saturates."
The Correct Approach: Cost-Based Limits
Per-endpoint rate limits should be derived from measured saturation thresholds. For each high-value endpoint, measure the request rate at which backend response time degrades by 50% or more from baseline. Set the WAF rate limit at 70-80% of that threshold to give headroom for legitimate traffic spikes while blocking attack rates. This requires load testing each endpoint individually, not just applying a global limit. DDactic's assessment automates this measurement: each discovered endpoint is probed at increasing request rates to determine its saturation point, and the resulting rate limit recommendation is specific to that endpoint.
Audit Your WAF Configuration
DDactic measures per-endpoint saturation thresholds and reports whether your current WAF configuration would catch an attack against each endpoint before the backend is affected.
Run a Free Scan