HTTP DoS is a denial-of-service attack that overwhelms a web service with excessive or expensive HTTP requests. Attackers aim to exhaust worker threads, CPU, memory, or backend capacity. Defenders should rate-limit requests, set timeouts, cache safely, and monitor unusual request volumes, slow responses, and repeated costly endpoints.
How HTTP DoS Works
HTTP DoS is usually effective because it does not need to break the application, it only needs to make each request expensive enough, or numerous enough, that normal traffic no longer gets served promptly. The service can be overwhelmed at the edge, inside the application layer, or in a backend dependency that every request must touch.
What makes this attack class dangerous is that HTTP traffic often looks legitimate at first glance. A small number of slow, repeated, or complex requests can consume the same worker pool and shared resources that real users depend on, especially when request handling involves authentication, database lookups, template rendering, file access, or API fan-out.
Common HTTP DoS Patterns
HTTP DoS is not one single technique. It can include high-volume request floods, repeated expensive searches, cache-bypass traffic, slow request bodies, or patterns that force the service to hold connections open. The practical effect is the same: capacity is diverted away from legitimate users.
Some variants are blunt and noisy, while others are deliberately low-rate and resource-efficient for the attacker. That means defenders cannot rely only on raw request count. They also need to watch request cost, concurrency, queue depth, backend latency, and whether a small set of endpoints is being hit disproportionately.
Why HTTP Services Are Vulnerable
Web services are vulnerable to HTTP DoS when the work per request is uneven. If a handful of requests can trigger expensive database queries, heavy JSON parsing, large response generation, or repeated upstream calls, an attacker can multiply that cost across many requests and exhaust capacity quickly.
Modern platforms also increase the blast radius by sharing infrastructure. A single overloaded route can saturate application workers, reverse proxies, caches, API gateways, or database pools, and one noisy tenant or endpoint can degrade service for everyone else.
Detection and Defensive Controls
Good defence focuses on both prevention and visibility. Rate limiting, request timeouts, connection limits, caching, circuit breakers, and queue controls all help reduce the amount of work a hostile client can force the service to do. Safe caching and careful backend design matter because they reduce the cost of repeat requests.
Monitoring should look beyond simple traffic spikes and track slow responses, repeated hits to expensive endpoints, abnormal retry behaviour, and rising resource use across worker pools and backend dependencies. For control alignment, OWASP API Security Top 10 is useful where the HTTP traffic is driving API-specific resource exhaustion or abuse of expensive flows, and NIST Cybersecurity Framework 2.0 helps structure the broader detect, protect, respond, and recover posture around availability loss.
Risk and Threat Considerations
HTTP DoS is dangerous because it converts ordinary-looking web requests into an availability attack against shared compute, application workers, and backend services. The immediate risk is outage or severe degradation, but the broader risk is that the service may appear partially healthy while real users experience timeouts, failed transactions, and cascading latency.
Failure mechanism: The attacker repeatedly triggers enough expensive request handling, concurrent connections, or backend fan-out to exhaust the service’s effective capacity before normal traffic can be served.
Impact: Users see slow responses, failed requests, dropped sessions, and degraded business services, and in severe cases dependent systems may also fail because they rely on the same overloaded HTTP path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | HTTP DoS often exploits expensive API work and resource exhaustion. |
| Recommendation — Limit costly API operations and cap per-client consumption to preserve availability. | ||
| NIST CSF 2.0 | PR.PS-01 — Service Protection | HTTP DoS is an availability attack against exposed web services. |
| DE.CM-01 — Networks and network services are monitored to detect potentially adverse events | HTTP DoS detection depends on noticing abnormal traffic and latency patterns. | |
| RS.MA-01 — Incident management is performed | HTTP DoS requires coordinated response when availability degrades or is attacked. | |
| Recommendation — Harden exposed services with throttling, timeouts, and resilient request handling. Monitor request volume, response time, and saturation signals for abuse or overload. Activate incident handling to triage, contain, and recover from availability degradation. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | HTTP DoS detection and investigation rely on request and response telemetry. |
| Recommendation — Log request patterns and analyze spikes, slow paths, and repeated failures. | ||
Practitioner Guidance
Why practitioners should care: HTTP DoS is often prevented less by any single control than by making expensive work difficult to trigger at scale. Treat high-cost endpoints, uncached flows, and shared backend dependencies as availability-critical paths.
What to watch for: A small number of routes dominating latency, worker exhaustion during modest traffic levels, or requests that stay cheap individually but become costly when repeated in volume should be treated as a sign of exposure.
Practitioner takeaway: The most effective defences are the ones that reduce per-request cost before scale turns into outage.