A Slow HTTP Attack is a denial of service technique that keeps web connections open for as long as possible, using very little traffic to exhaust server resources. The attacker sends incomplete or slow requests, causing the web server, proxy, or load balancer to hold sockets, threads, or session capacity until legitimate users are blocked.
How Slow HTTP Attacks Work
A slow HTTP attack abuses the normal expectation that a request will arrive and finish promptly. By dribbling headers or body data just fast enough to stay alive, the attacker ties up connection state and starves the server of capacity for real users.
The technique is effective because many web stacks reserve sockets, worker threads, or proxy slots while they wait for a request to complete. That means a relatively small amount of attacker traffic can create a much larger availability problem than a conventional flood.
Why They Disrupt Web Infrastructure
Slow HTTP attacks are especially disruptive when they hit front-end components that multiplex traffic for many users. Reverse proxies, application servers, and load balancers can all become bottlenecks if they must hold open too many incomplete connections at once.
The danger is not just raw exhaustion, but resource pinning. A connection that looks legitimate may consume state for longer than expected, which reduces throughput and can trigger timeouts, queue growth, and cascading latency for other requests.
Common Variants and Abuse Patterns
Defenders often encounter several related patterns under the slow HTTP umbrella, including slow header delivery and slow request body delivery. The common theme is that the client intentionally avoids finishing the request quickly enough for the server to free the slot.
These attacks are attractive because they can be low-bandwidth, intermittent, and hard to distinguish from poor network conditions without careful telemetry. That makes them useful for exhausting capacity while blending into ordinary traffic patterns.
When the technique is combined with distributed sources or repeated across many connections, it can overwhelm per-client limits and make simple rate-based blocking less effective.
How Organisations Assess and Reduce Exposure
Exposure starts with understanding which internet-facing services hold connections open and which tiers have the narrowest concurrency limits. A useful assessment looks at reverse proxies, application servers, idle timeout settings, request buffering, and whether the service is reachable directly or only through a front door.
For authoritative guidance on hardening the broader web stack, use the vendor or platform documentation for your proxy or load balancer, and consult CISA cyber threat advisories for active abuse patterns and mitigation priorities. Where request framing disagreements or desynchronisation are part of the environment, HTTP Request Smuggling Guide is a useful adjacent reference because proxy parsing and connection handling often sit close together in the same defence boundary.
Risk and Threat Considerations
Slow HTTP attacks are a denial-of-service concern even when the attacker sends very little data. The practical risk is availability collapse at the edge: a modest number of lingering connections can consume enough shared capacity to block legitimate traffic and amplify latency across the service chain.
Failure mechanism: The attacker keeps sessions half-open or slow enough that the server, proxy, or load balancer continues reserving scarce connection and worker resources instead of recycling them.
Impact: Users experience timeouts, failed logins, stalled pages, and degraded service, and in severe cases the protected application can become unreachable until the stale connections clear.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Slow HTTP attacks exploit exposed web infrastructure and connection handling. |
| Recommendation — Tune perimeter web and proxy settings to limit long-lived connections and resource exhaustion. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Connection timeouts and proxy settings are core protective configurations against slow HTTP abuse. |
| DE.CM-01 — Network Monitoring | Detection depends on spotting anomalous connection duration and saturation patterns. | |
| Recommendation — Harden exposed services with tested timeout and connection limits. Monitor for many partial or long-lived connections with low request volume. | ||
| OWASP ASVS | V12 — Secure Communication | HTTP connection handling and request framing are part of secure transport behavior for web applications. |
| Recommendation — Verify that web services enforce predictable request completion and connection teardown. | ||
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | This control directly addresses resource-exhaustion conditions like slow HTTP attacks. |
| Recommendation — Apply denial-of-service protections that bound open connections and protect server capacity. | ||
Practitioner Guidance
What to watch for: Treat unusually long-lived partial requests, high counts of open but idle sockets, and worker saturation with low traffic volume as early warning signs. Those signals matter more than raw request volume in a slow HTTP scenario.
Governance implication: Owners should set clear timeout and connection-management baselines for every internet-facing tier, then validate that the proxy, web server, and application all enforce them consistently. When the front end and back end disagree on how long to wait, the attacker gets room to hold resources open.