DoS vs DDoS vs Decompression Bomb: A Developer's Field Guide

"Denial of service" gets used as if it's one attack. It isn't. DoS, DDoS, and decompression bombs are three different problems with three different defenses, and mixing them up in an interview (or a production setup) is a quick way to look like you don't know what you're talking about.

Here's the field guide.

DoS (Denial of Service)

A DoS attack is any attack that makes a service unavailable to its legitimate users. The "denial" is of service; the mechanism is wide open.

A DoS can be:

• A resource exhaustion attack — one attacker sends requests that consume CPU, memory, disk, or connections until the server can't serve anyone else.
• A logic attack — one attacker sends a crafted request that crashes the service (e.g., a regex that causes catastrophic backtracking, a payload that triggers an unhandled exception).
• A slow attack — one attacker opens connections and holds them open barely-sending-anything (Slowloris), exhausting the connection pool.

The defining feature: one source, one target. A DoS comes from one machine (or a small number). It's the simplest form of denial-of-service.

Defending against DoS

• Rate limiting per IP / per user / per endpoint. Cap how much any single source can ask of you.
• Request size + time limits. Cap body size, request timeout, slow-client timeout.
• Input validation. Reject payloads that would cause expensive processing (deeply nested JSON, catastrophic regexes, oversized fields).
• Resource caps. Cap CPU/memory per request, cap concurrent connections per source.

A single-source DoS is the easiest to defend against — if you've done the basics, one machine can't take you down.

DDoS (Distributed Denial of Service)

A DDoS attack is a DoS attack launched from many sources simultaneously — typically thousands or millions. The sources are usually a botnet of compromised devices (IoT cameras, routers, infected PCs) or a "booter/stresser" service renting out attack capacity.

The defining feature: many sources, one target. Because the traffic comes from everywhere, you can't just block one IP. Rate-limiting per IP doesn't help when each IP sends only a little.

DDoS attacks come in a few flavors:

• Volumetric attacks — flood the target with more bandwidth than it can handle (UDP floods, amplification attacks like DNS or NTP reflection). The target's network link saturates; legitimate traffic can't get through.
• Protocol attacks — exploit weaknesses in network protocols (SYN floods, Ping of Death, fragmented packet floods). The target's OS or network stack gives up before the bandwidth does.
• Application-layer attacks — send HTTP requests that look legitimate to a firewall but are expensive to process (requesting the heaviest page, triggering expensive database queries, hitting search endpoints with regex-heavy queries). Harder to detect because the traffic looks "normal."

Defending against DDoS

• A CDN / reverse proxy in front of your origin. Cloudflare, Fastly, AWS CloudFront, Google Cloud Armor. They absorb volumetric attacks at their edge — your origin never sees the traffic.
• Anycast networking. Distribute the attack across many points of presence, so no single location is overwhelmed.
• Bot management / WAF rules. Challenge suspicious traffic with a CAPTCHA or JavaScript challenge. Block known bot signatures.
• Rate limiting at the edge. Cloudflare and friends can rate-limit by IP, ASN, or JA3 fingerprint before traffic hits you.
• Autoscaling + overflow. If you can't block it, survive it: autoscale to absorb the load, and shed low-priority traffic (e.g., disable search, serve cached pages) to keep critical paths working.

The key insight: you cannot defend against a real DDoS from your own server. By the time the traffic reaches you, your network link is already saturated. You need a third party with much bigger pipes standing in front of you. Cloudflare's free plan is enough for most small sites.

Decompression bomb (a specific kind of DoS)

A decompression bomb (also called a "zip bomb" or "compression bomb") is a resource-exhaustion DoS where a small input expands to a huge output during decompression.

The canonical example: 42.zip, a 42 KB file that expands to 4.5 petabytes when fully decompressed. A newer 2019 variant by David Fifield uses overlapping zip entries to achieve the same expansion in a single 46 MB file without nesting.

The attack works because input size is not a proxy for processing cost. A 42 KB upload can cost your server petabytes of work if it naively decompresses everything.

How it plays out

An attacker uploads a zip bomb to your file-upload endpoint. Your server starts decompressing — allocating memory, writing to disk, recursing into nested archives. CPU pegs to 100%, disk fills, RAM exhausts. The server can't respond to legitimate requests. That's a DoS, achieved via decompression.

Defending against decompression bombs

This is the part most explainers get wrong. Rate limiting and WAFs help with traffic DoS, but they don't help here. The fix is different:

• Cap decompression size and ratio. Set a hard maximum on total output bytes (e.g., refuse anything that would decompress beyond 1 GB for an upload endpoint). Check the ratio too — if a 1 MB file claims to decompress to 10 GB, refuse it.
• Cap recursion depth. Refuse nested archives deeper than 3–5 layers.
• Stream, don't buffer. Decompress with a streaming approach and a kill switch — the moment cumulative output crosses your threshold, abort.
• Verify file type by magic bytes, not extension. Don't trust the .zip suffix.
• Run extraction in a sandbox with strict memory/CPU/time limits (a container with cgroups, a lambda with a tight timeout).

The taxonomy, summarized

| Attack | Sources | Mechanism | Primary defense | |---|---|---|---| | DoS | One (or few) | Resource exhaustion, logic, slow | Rate limiting, input validation, resource caps | | DDoS | Many (botnet) | Volumetric, protocol, application-layer | CDN/edge (Cloudflare), anycast, bot management | | Decompression bomb | One | Small input → huge output during decompression | Decompression size/ratio caps, streaming, sandbox |

Notice: a decompression bomb is technically a kind of DoS (it denies service via resource exhaustion). But it's worth naming precisely because its defense is totally different from the traffic-based DoS/DDoS defenses. "We have Cloudflare" doesn't protect you from a zip bomb uploaded through your own form.

The interview-ready version

If someone asks "what's the difference between DoS and DDoS?":

A DoS comes from one source; a DDoS comes from many. The defense differs: DoS is handled with rate limiting and input validation on your own server, while DDoS requires a third-party CDN or scrubbing service because the traffic volume saturates your network link before it reaches you.

If they ask about zip bombs:

A zip bomb is a specific kind of DoS where a small compressed file expands to a huge size during decompression — the famous 42.zip is 42 KB but expands to 4.5 petabytes. The defense isn't rate limiting; it's capping decompression size and ratio, streaming with a kill switch, and running extraction in a sandbox with resource limits. It's technically a resource-exhaustion DoS, but worth naming precisely because the mitigation is different.

Run the checklist

The ShipReady Security section covers rate limiting, WAF/DDoS protection, and file upload validation as separate items — because they defend against different things. The Reliability section covers timeouts, circuit breakers, and graceful degradation.

Run the checklist before you ship. Knowing the difference between these attacks is the theory; having the defenses in place is the practice.