Slow HTTP Attack

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.

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.

Related resources from NHI Mgmt Group

• Attack Surface Management
• What signals show that identity response is too slow for modern attack pacing?
• What breaks when fraud defenses are too slow to adapt to new attack vectors?
• What breaks when fraud teams rely on manual rules and slow model updates during fast-changing attack patterns?