A Denial of Service (DoS) attack is an attempt to make a system, application, or network unavailable to its legitimate users by overwhelming it with traffic or exploiting a flaw that exhausts its resources. Unlike a data breach, a DoS attack usually isn't trying to steal anything — it's trying to break something. That distinction matters for how security teams prioritize it: a DoS attack can knock a hospital's patient portal offline, take a trading platform out during market hours, or silence a news site during a breaking story, all without a single record being exfiltrated. On October 21, 2016, a botnet of roughly 100,000 compromised IoT devices called Mirai flooded DNS provider Dyn with traffic, and Twitter, Netflix, Reddit, and Spotify went dark for hours across the US East Coast. That single incident reframed availability as a security problem, not just an infrastructure one.
How Does a Denial of Service Attack Actually Work?
A DoS attack works by consuming a finite resource faster than a system can replenish or process it, so legitimate requests get dropped or queued indefinitely. That resource can be network bandwidth, server CPU, memory, open connections, or application-layer capacity like database connections or regex processing time. Volumetric attacks saturate bandwidth with raw traffic — on February 28, 2018, GitHub was hit with a 1.35 Tbps memcached amplification attack that lasted about eight minutes before Akamai's Prolexic scrubbing service absorbed it. Protocol attacks target the handshake mechanics of TCP/IP itself, like a SYN flood that opens thousands of half-completed connections and never finishes them. Application-layer attacks are subtler: a Slowloris attack, first documented by researcher Robert "RSnake" Hansen in 2009, opens many HTTP connections and sends partial requests slowly, holding worker threads open until the server has none left to serve real users.
What's the Difference Between a DoS and a DDoS Attack?
The difference is the number of sources: a DoS attack originates from one machine, while a Distributed Denial of Service (DDoS) attack originates from many machines at once, usually a botnet. A single attacker running a Slowloris script against a small web server is a DoS attack. Coordinating tens of thousands of hijacked IoT cameras and routers to fire traffic at the same target simultaneously — as Mirai did to Dyn in 2016 — is a DDoS attack, and it's the far more common form in the wild today because distributed traffic is harder to filter and its scale is orders of magnitude larger. In February 2020, AWS Shield mitigated a 2.3 Tbps DDoS attack against a CloudFront customer using CLDAP reflection, a scale that would be practically impossible for a single-source DoS attack to reach. Most enterprise incident response plans now use "DoS" as the umbrella term for the attack class and "DDoS" to describe the delivery mechanism.
What Are the Most Common Types of DoS Attacks Security Teams See Today?
The most common types fall into three buckets: volumetric floods, protocol exploits, and application-layer resource exhaustion, and in 2023 the dominant new threat was an application-layer technique called HTTP/2 Rapid Reset. Tracked as CVE-2023-44487 and disclosed in October 2023, Rapid Reset abuses HTTP/2's stream cancellation feature to open and immediately reset requests in rapid succession, forcing servers to do the work of starting a request without ever completing one. Google reported mitigating a peak of 398 million requests per second from this technique, Cloudflare saw 201 million rps, and AWS saw over 155 million rps — each a record at the time, achieved with botnets far smaller than those needed for equivalent volumetric floods. Amplification attacks remain common too: attackers spoof a target's IP address and send small requests to open DNS, NTP, or memcached servers, which reply with responses many times larger than the request, as happened in the GitHub memcached incident. Regular expression denial of service (ReDoS) is a fourth, code-level category worth flagging separately: a poorly written regex with catastrophic backtracking can pin a CPU core at 100% processing a single crafted input, and it doesn't require any network flood at all.
How Costly Are DoS Attacks in Practice?
DoS attacks are costly primarily through downtime, and the numbers are not abstract. Gartner has estimated the average cost of IT downtime at roughly $5,600 per minute, which translates to over $300,000 per hour for a typical enterprise outage. The Mirai-driven Dyn attack in October 2016 disrupted access to dozens of major platforms for the better part of a business day across the eastern United States. A less obvious but equally instructive example: on July 2, 2019, Cloudflare suffered a global outage not from an external attacker but from a single overly broad regular expression in a WAF rule, which triggered catastrophic backtracking and spiked CPU usage to 100% across its network for 27 minutes, degrading service for a large share of the internet traffic Cloudflare fronts. The lesson security teams should take from that incident specifically is that DoS risk isn't only an inbound-traffic problem — it's also a code-quality and dependency problem, since the same ReDoS pattern can sit dormant in application or open-source code for years before an attacker (or a legitimate user) triggers it.
How Can You Tell If You're Under a DoS Attack?
You can tell you're under a DoS attack when you see a sudden, disproportionate spike in traffic, connection counts, or resource consumption that doesn't match normal usage patterns for the time and source. Concrete signals include: response times climbing from milliseconds to seconds or timing out entirely, a spike in connections from a narrow set of IP ranges or ASNs, unusually high volumes of a single request type (for example, the same URL or API endpoint hit thousands of times per second), and server-side metrics showing CPU, memory, or database connection pools pinned near 100% while request throughput drops. During the 2023 HTTP/2 Rapid Reset wave, the tell was a flood of streams that opened and reset within milliseconds — a pattern invisible to volumetric-only monitoring but obvious once teams instrumented stream-level HTTP/2 metrics. Distinguishing an attack from an organic traffic surge (a product launch, a viral post) matters because the remediation is different: rate limiting and WAF rules for an attack, autoscaling for a legitimate surge.
How Do You Defend Against DoS Attacks?
You defend against DoS attacks with a layered approach: upstream traffic scrubbing for volumetric floods, protocol-level hardening for handshake abuse, and code-level fixes for application-layer exhaustion bugs like ReDoS. Cloud-based scrubbing services (Akamai Prolexic, Cloudflare, AWS Shield) absorbed the record-setting attacks against GitHub in 2018 and the CloudFront customer in 2020 precisely because they can distribute the flood across globally distributed capacity that no single origin server has. Rate limiting, SYN cookies, and connection timeouts blunt protocol-level attacks like SYN floods and Slowloris. But the category that traditional DDoS mitigation tools miss entirely is the application-layer bug sitting in your own code or a third-party dependency — a vulnerable regex library, an unbounded loop triggered by attacker-controlled input, or a recursive parser with no depth limit. Those require finding and fixing the vulnerable code itself, not just filtering traffic at the edge, which is why DoS defense has become as much a software composition and code-scanning problem as a network security one.
How Safeguard Helps
Safeguard treats DoS risk as both a network problem and a code problem, and focuses its analysis on the second half most security tools ignore. Reachability analysis determines whether a known DoS-capable vulnerability — a ReDoS pattern, an unbounded resource allocation, a known CVE like the HTTP/2 Rapid Reset class of bugs — actually sits on a code path your application executes, cutting through the noise of dependency scanners that flag every CVE in your SBOM regardless of exploitability. Griffin AI, Safeguard's reasoning engine, reads the vulnerable function and the calling code together to judge whether attacker-controlled input can actually reach the resource-exhaustion trigger, rather than relying on version-string matching alone. Safeguard generates and ingests SBOMs across your services so you always know which packages carry DoS-relevant flaws, and when a fix is available, Safeguard opens an auto-fix PR with the patched dependency version so the exposure window closes in minutes rather than in the next scheduled sprint.