{"id":1005417,"date":"2026-10-15T12:36:11","date_gmt":"2026-10-15T04:36:11","guid":{"rendered":"\/en\/?p=1005417"},"modified":"2026-10-15T15:44:32","modified_gmt":"2026-10-15T07:44:32","slug":"denial-of-service-attack","status":"publish","type":"post","link":"\/en\/article\/denial-of-service-attack","title":{"rendered":"Denial-of-Service (DoS) Attack: Types, Signs, and Prevention"},"content":{"rendered":"
\n

A denial-of-service (DoS) attack is an intentional attempt to make a service unavailable or materially slower for legitimate users. It consumes a resource the service needs: bandwidth, connection state, CPU, memory, database capacity, queue space, or the processing budget of an expensive application function.<\/p>\n\n\n\n

The useful incident question is not simply \u201cHow much traffic arrived?\u201d It is \u201cWhat resource is being exhausted, which requests are consuming it, and which control owns that layer?\u201d That distinction guides teams toward edge protection, origin resilience, demand shaping, or selective application-layer controls.<\/p>\n\n\n\n

What Is a Denial-of-Service Attack?<\/h2>\n\n\n\n

A DoS attack disrupts normal service without necessarily breaking into the target. An attacker may send a large volume of traffic, hold connections open, or repeatedly invoke a costly function. The result can be latency, timeouts, failed jobs, growing queues, 5xx responses, or an outage.<\/p>\n\n\n\n

The same symptoms can have non-malicious causes: a product launch, software regression, retry storm, failing dependency, or misconfigured client. A traffic spike is evidence to investigate, not proof of an attack. Compare the incident with a healthy baseline and correlate edge logs, application traces, origin metrics, dependency health, and representative sessions.<\/p>\n\n\n\n

The CISA guidance on denial-of-service attacks<\/a> explains the availability objective and the need for preparation. An internal plan still needs endpoint ownership, escalation contacts, safe-degradation rules, and recovery steps.<\/p>\n\n\n\n

DoS vs DDoS: What Is the Difference?<\/h3>\n\n\n\n

Both attacks aim to disrupt availability. A DoS attack commonly comes from one source or a smaller set of sources; a distributed denial-of-service (DDoS) attack coordinates many sources, often through a botnet. Distribution makes filtering and attribution harder. For the separate DDoS topic, see the DDoS prevention guide<\/a>. This page focuses on DoS resource exhaustion and control boundaries.<\/p>\n\n\n\n

Dimension<\/th>DoS<\/th>DDoS<\/th><\/tr><\/thead>
Source pattern<\/td>One or a smaller set of sources<\/td>Many distributed sources<\/td><\/tr>
Main challenge<\/td>Isolate the abusive flow<\/td>Aggregate signals and use upstream controls<\/td><\/tr>
Page ownership here<\/td>Primary topic<\/td>Related article only<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

How Do DoS Attacks Exhaust Resources?<\/h2>\n\n\n\n
Resource<\/th>What happens<\/th>Typical symptom<\/th>Primary owner<\/th><\/tr><\/thead>
Bandwidth<\/td>More traffic arrives than links or edge capacity can carry<\/td>Saturated links and broad timeouts<\/td>Network, CDN, DDoS provider<\/td><\/tr>
Connection state<\/td>Handshakes or sessions stay open at scale<\/td>Half-open connections and exhausted tables<\/td>Network and infrastructure<\/td><\/tr>
Compute, database, or queue<\/td>Work-heavy requests consume capacity<\/td>CPU\/database waits and queue growth<\/td>Platform, SRE, application<\/td><\/tr>
Business endpoint budget<\/td>Search, login, reports, checkout, or APIs repeat<\/td>One endpoint dominates origin load<\/td>App security and product<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

An application-layer campaign can look moderate at the edge while being destructive. One search request may trigger several database calls. One login attempt may invoke identity checks, fraud rules, and session creation. Cache bypass and retries can multiply the work.<\/p>\n\n\n\n

What Are Common DoS Attack Types?<\/h2>\n\n\n\n

Volumetric pressure<\/h3>\n\n\n\n

Volumetric attacks consume bandwidth or edge capacity. The response involves upstream filtering, CDN capacity, traffic scrubbing, routing changes, and provider escalation. A CAPTCHA cannot repair a saturated link.<\/p>\n\n\n\n

Protocol and connection-state pressure<\/h3>\n\n\n\n

Protocol or state attacks consume connection tables and network-device resources. Connection limits, network filtering, resilient edge configuration, and infrastructure monitoring own this layer.<\/p>\n\n\n\n

Application-layer request floods<\/h3>\n\n\n\n

These requests may look valid but are expensive to process. Login, search, report generation, inventory, checkout, and API endpoints are common targets. Investigate endpoint cost, cache behavior, account state, session depth, and response time\u2014not only IP volume.<\/p>\n\n\n\n

Retry and amplification pressure<\/h3>\n\n\n\n

Aggressive retries, queue fan-out, or a failing dependency can amplify a smaller incident into a thundering herd. Backoff, idempotency, queue limits, and graceful degradation belong in the availability plan.<\/p>\n\n\n\n

How Can Teams Detect a DoS Attack?<\/h2>\n\n\n\n

Start with a known-good baseline and compare it with the incident window. Look for:<\/p>\n\n\n\n