What Is Denial of Service (DoS)?

A denial of service attack makes a system unavailable to its legitimate users. In its single-source form it works by exhausting a specific resource rather than by overwhelming a connection with volume.

That distinction matters, because the effective single-source attacks are usually application flaws. They consume disproportionate resources from a small request, which makes them a development problem rather than a capacity one. For the distributed form see DDoS.

Resource exhaustion, not bandwidth

Connection state, where many half-open connections consume tracking resources. Memory, through requests that allocate heavily. Processor time, through operations that are expensive to compute.

Disk, through requests that generate large logs or temporary files. Database connections, which are usually a small pool. And any third-party quota the application depends on, where exhausting your own rate limit denies service to everyone.

Algorithmic complexity attacks

The most elegant version finds input that triggers worst-case behaviour in an algorithm: a regular expression that takes exponential time on a crafted string, a hash table forced into collisions, a parser made to recurse deeply, a compressed payload that expands enormously.

One small request can consume a server for seconds or minutes. These are code defects, they are found by testing with deliberately hostile input, and they are invisible to capacity planning.

Application-layer rate limiting

Limits should sit on expensive operations rather than on requests generally: search, report generation, export, authentication, anything invoking a third-party service.

Per-account and per-address limits, timeouts on every external call, bounded queues, and caps on request and upload size. Most of this is design discipline rather than infrastructure.

Self-inflicted outages are more common

Most availability incidents are not attacks. A retry loop without backoff, a misconfigured monitoring check, a deployment that multiplies database queries, or a legitimate traffic spike from a marketing campaign all produce the same symptom.

The engineering that defends against deliberate exhaustion — limits, timeouts, backpressure, graceful degradation — is the same engineering that prevents these, which is usually the more persuasive justification for it.

Testing for it

Load testing establishes capacity under normal traffic shapes. It does not find algorithmic attacks, which require deliberately hostile input rather than more of the ordinary kind.

Fuzzing with pathological input, reviewing regular expressions for catastrophic backtracking, and testing decompression and parsing limits are the specific activities. They belong in application testing scope and are frequently omitted.

Availability is a security property

Confidentiality and integrity receive most of the attention, and unavailability is what a hospital, a manufacturer or a payment processor actually cannot tolerate. Several regulatory frameworks treat availability as a control objective for exactly that reason.

Framing it that way changes who owns the work. Timeouts, limits, capacity headroom and graceful degradation sit with engineering rather than security, and the security contribution is usually making the case for them rather than implementing them.

Where to start

Check whether your expensive endpoints — search, export, report generation — have rate limits and timeouts. Those are where a single-source attack succeeds.

See API security. GuardsArm delivers application penetration testing.