Resource Exhaustion: Starving a System to Death

Why it exists

Systems are built with finite resources: a limited amount of CPU cycles, memory, and network connections. Resource exhaustion attacks exist to exploit this fundamental constraint, making a service unavailable not by crashing it with a bug, but by legitimately requesting resources until none are left for real users.

The mental model

Think of a public library with a limited number of checkout slots. A resource exhaustion attack is like one person checking out every single book, not to read them, but simply to ensure no one else can. The system is working as designed—it's checking out books—but its availability is compromised because one user has consumed the entire shared resource pool.

How it works

An attacker identifies a finite, consumable resource on the target system. This could be low-level (CPU, RAM, disk I/O) or application-level (database connections, file handles, worker threads). The attacker then repeatedly makes requests that consume a small amount of that resource but never release it, or release it very slowly. For example, initiating many TLS handshakes without completing them (consuming CPU) or opening many database connections and leaving them idle (consuming connection pool slots). Over time, the resource pool is depleted, and the system can no longer serve legitimate requests, leading to a denial of service.

When to use it

This isn't a technique you "use," but one you defend against. You might simulate one during chaos engineering experiments to test your system's resilience. For example, you could intentionally leak memory or hold database connections open to see if your monitoring alerts, if your circuit breakers trip, or if the system gracefully degrades instead of crashing hard. This helps validate that your quotas, rate limits, and auto-scaling policies work under pressure.

When not to use it

Do not simulate this kind of attack in production without explicit, well-communicated planning and the ability to immediately halt the experiment. A poorly planned test can easily become a self-inflicted production outage, impacting real users and revenue. The goal is to build confidence, not to break things recklessly. Always have a kill switch for any chaos experiment.

One canonical example

The "Slowloris" attack is a classic example. An attacker opens many connections to a web server and keeps them alive by sending partial HTTP requests very slowly, but never completing them. The web server keeps these connections open, waiting for the rest of the data. Because servers have a finite limit on concurrent connections, the attacker can eventually tie up all available connection slots, preventing any legitimate users from connecting. The server itself isn't crashed, but it's completely unavailable.