Skip to content

Archive

Denial of Service

3 articles
Cybersecurity 10 Sep 2026 8 min read

Bound Decompression Before Processing Untrusted Data

A compressed request or uploaded archive can look harmless when its byte count is small. The server may discover a very different workload after decompression: far more output bytes, memory use, disk writes, or nested work than the original input suggested. That gap matters whenever an attacker can supply compressed data. If the application limits only the compressed input size, a small request can still force expensive expansion and exhaust resources needed by other users. The defensive goal is not to guess which compressed files are malicious. It is to put a hard boundary around the work the application is willing to perform.

Cybersecurity 09 Sep 2026 10 min read

Rate Limit by the Resource an Attacker Can Exhaust

A rate limit can look effective in testing and still fail against the abuse it was meant to control. The usual reason is not the counter or the algorithm. It is the key used to group requests. Suppose a password-recovery endpoint allows five requests per hour from each source address. That may slow one client, but it does not directly protect a user’s mailbox from receiving hundreds of recovery messages sent through many source addresses. The resource under pressure is the destination account or delivery channel, while the limit is counting something else.

Cybersecurity 06 Sep 2026 11 min read

Bound Work Before Processing Untrusted Input

An input does not need to be malicious code to hurt a service. It only needs to make the service spend far more memory, CPU time, storage, or concurrency than the sender spent creating the request. A parser may accept deeply nested data. A compressed upload may expand far beyond its transfer size. A search endpoint may allow a query that is valid but unusually expensive. If enough work begins before the application applies a limit, a small amount of incoming traffic can consume resources needed by legitimate users.