Slowloris is a denial-of-service technique that keeps many server connections open for a long time while sending data very slowly. Technically, it exploits limits on concurrent connections and request timeouts, exhausting available resources without needing much bandwidth, which can disrupt web services, gateways, and other networked applications.
How Slowloris Works
Slowloris is an application-layer denial-of-service technique that aims to keep server-side connections tied up for as long as possible while transmitting data very slowly. It is effective because many web servers and gateways allocate connection handling resources before a request is complete, so a small amount of traffic can consume disproportionate capacity.
The technique does not rely on high bandwidth or packet floods. Instead, it exploits the way some services manage concurrent connections and request timeouts, which makes it especially relevant to HTTP services and other networked applications that depend on limited worker pools, socket tables, or similar per-connection resources.
Why Slowloris Is Effective
Slowloris works best where a service assumes requests will either complete quickly or time out cleanly. By deliberately withholding full request completion, the attacker creates a resource pinning effect, each open connection remains useful to the attacker but costly to the target.
This makes the technique attractive against environments that have many exposed endpoints but modest connection capacity, such as reverse proxies, load balancers, application gateways, and older web stacks. The service may still appear reachable, yet real users experience long waits, failed logins, or stalled page loads because the available concurrency has been consumed.
Its danger is not only outage, but also deceptive degradation. Operators may see low traffic volume and underestimate the attack, even while legitimate requests are being denied because the server has run out of usable connection slots.
What Organisations Should Check
Exposure starts with knowing which systems accept untrusted client connections and how those systems enforce idle, header, and request-completion timeouts. Internet-facing web servers, API gateways, and middleware that terminate client sessions deserve the closest review because they are the most common choke points for this technique.
Capacity settings matter as much as patching. If one reverse proxy or gateway sits in front of many applications, a connection-exhaustion problem there can create a broad service impact that looks larger than the original target. This is why the operational question is not just whether the application is vulnerable, but whether the deployment path concentrates all client traffic through a small number of front doors.
A practical review should include vendor guidance for the specific server or proxy in use, since timeout handling, keep-alive behavior, and connection accounting vary across products. For wider hardening patterns, the DDoS Protection Guide covers the broader defensive model that Slowloris fits into.
Mitigation and Detection
Defence usually combines protocol tuning, traffic controls, and resilient front-end design. Shorter header and request timeouts, per-client connection limits, reverse proxies, load balancers, and rate limiting can all reduce the chance that a small number of slow connections monopolise service resources.
Detection should focus on abnormal connection longevity, incomplete requests, and rising concurrency with unusually low throughput. The useful signal is often a mismatch, many open sessions, little completed work, and no corresponding rise in normal business traffic. That pattern helps distinguish Slowloris from ordinary spikes in demand.
Post-incident review should also check whether the service recovered cleanly after the slow connections were dropped. If users remained unable to connect after the attack stopped, the issue may have exposed a deeper capacity, timeout, or proxy-configuration weakness rather than a one-off event.
Why It Matters for Service Availability
Slowloris is important because it shows that availability failures do not require large-scale traffic floods. A low-volume, resource-holding attack can still disrupt web services, authentication portals, admin consoles, and any application that depends on a finite pool of client-facing connections.
For practitioners, the key lesson is that connection management is part of availability design. If timeout policy, concurrency limits, and front-end buffering are weak, a service can be taken down by behavior that looks small in packet terms but large in operational effect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Slowloris is detected and constrained through monitoring, rate limiting, and edge defense. |
| Recommendation — Tune edge monitoring and throttling to detect low-bandwidth connection-exhaustion patterns early. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Timeouts, concurrency, and proxy behavior are configuration choices that shape Slowloris exposure. |
| DE.CM-01 — Network Monitoring | Connection buildup and abnormal session persistence are monitoring signals for Slowloris activity. | |
| RS.MA-01 — Incident Management | Slowloris disruption is handled through service restoration and traffic containment actions. | |
| Recommendation — Harden service and proxy settings so slow connections cannot monopolize resources. Watch for many long-lived incomplete connections and investigate resource-exhaustion anomalies. Use incident handling procedures to restore availability and contain abusive client connections. | ||