Denial-of-Service (DoS) Attack: Types, Signs, and Prevention

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.

The useful incident question is not simply “How much traffic arrived?” It is “What resource is being exhausted, which requests are consuming it, and which control owns that layer?” That distinction guides teams toward edge protection, origin resilience, demand shaping, or selective application-layer controls.

What Is a Denial-of-Service Attack?

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.

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.

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

DoS vs DDoS: What Is the Difference?

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. This page focuses on DoS resource exhaustion and control boundaries.

Dimension	DoS	DDoS
Source pattern	One or a smaller set of sources	Many distributed sources
Main challenge	Isolate the abusive flow	Aggregate signals and use upstream controls
Page ownership here	Primary topic	Related article only

How Do DoS Attacks Exhaust Resources?

Resource	What happens	Typical symptom	Primary owner
Bandwidth	More traffic arrives than links or edge capacity can carry	Saturated links and broad timeouts	Network, CDN, DDoS provider
Connection state	Handshakes or sessions stay open at scale	Half-open connections and exhausted tables	Network and infrastructure
Compute, database, or queue	Work-heavy requests consume capacity	CPU/database waits and queue growth	Platform, SRE, application
Business endpoint budget	Search, login, reports, checkout, or APIs repeat	One endpoint dominates origin load	App security and product

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.

What Are Common DoS Attack Types?

Volumetric pressure

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.

Protocol and connection-state pressure

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

Application-layer request floods

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—not only IP volume.

Retry and amplification pressure

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.

How Can Teams Detect a DoS Attack?

Start with a known-good baseline and compare it with the incident window. Look for:

• bandwidth, concurrent connections, half-open connections, or origin CPU rising sharply;
• latency and errors concentrated on one or two endpoints;
• queue depth, database waits, connection-pool exhaustion, or dependency timeouts;
• cache bypass or repeated requests for dynamic resources;
• high IP churn, repeated device or session patterns, or unusual geographic concentration;
• shallow sessions, repeated login or token attempts, or requests that never reach a meaningful page state; and
• retries increasing after latency rises, creating additional recovery pressure.

No single signal proves that bots caused the incident. Correlate edge logs with traces, endpoint cost, account state, origin metrics, and a sample of sessions before blocking. The goal is to identify expensive untrusted work without turning a legitimate event, shared network, accessibility need, or recovering customer into a false positive.

A practical triage sequence starts at the widest layer and narrows inward. First, confirm whether the link or edge is saturated. Next, check whether connection state is exhausted. Then identify which origins, dependencies, queues, and endpoints are slow. Finally, compare request characteristics and user journeys. If the edge is healthy but one uncached endpoint consumes most database time, a network-wide block is unlikely to be the best first response. If the link is saturated, an application challenge will be too late to help.

Preserve evidence while the incident is active. Record timestamps, emergency-rule changes, provider tickets, representative request IDs, and the point at which service recovered. This makes the post-incident review more reliable and helps teams distinguish the control that restored availability from changes that happened at the same time.

How Can Organizations Prevent and Respond to DoS Attacks?

Use layers with explicit ownership:

1. Protect the edge. Use CDN capacity, WAF rules, traffic scrubbing, connection limits, routing controls, and provider escalation.
2. Protect the origin. Use caching, origin isolation, autoscaling, queueing, endpoint budgets, database tuning, and graceful degradation.
3. Shape demand. Apply rate limits, waiting rooms, backoff guidance, idempotency controls, and endpoint-specific admission policies.
4. Monitor and rehearse. Alert on latency percentiles, error budgets, queue age, database waits, cache bypass, and unusual request distributions.
5. Recover deliberately. Restore essential paths first, then re-admit traffic gradually so retries do not cause a second collapse.

After an incident, measure endpoint latency, queue age, time to restore service, challenge or block rate, false-positive reports, and user impact. A rule that lowers origin load but blocks legitimate users may be a poor control.

The ICO denial-of-service guidance treats availability as an organizational risk, not only a network problem.

Assign ownership before an incident

Platform or SRE teams normally own capacity, queues, dependencies, and safe degradation. Network and infrastructure providers own routing and traffic-scrubbing actions. Security and abuse teams investigate automation signals and tune admission policy. Product and support teams decide which customer journeys must remain available and how a challenged or rejected user can recover. Writing those handoffs down before an incident is more valuable than adding a single emergency rule after the origin is saturated.

The response should also distinguish containment from recovery. A temporary rate limit may protect a database while an incident team confirms the source, but it should have an expiry, an owner, and a rollback condition. A challenge that reduces automated work may still be the wrong choice if it creates an accessibility barrier or blocks legitimate users behind a shared network. Track those tradeoffs alongside latency and error budgets.

Where Do Application-Layer Bot Controls Fit?

Application-layer controls are useful when suspicious automation reaches an expensive action but the platform still has enough capacity to make a risk decision. Low-risk users should continue with minimal friction; higher-risk sessions can receive a step-up or policy decision before costly business logic runs.

For context, see bot-traffic detection guidance and effective bot-detection practices. Combine behavior signals with IP reputation, device context, account state, velocity, endpoint cost, and business rules. They are evidence for a decision, not proof of identity.

GeeTest Adaptive CAPTCHA can be evaluated as one selective risk-based verification layer for login, registration, promotion, or another high-cost workflow. Device fingerprinting context can contribute another signal. Place the challenge before expensive work where possible and provide a recovery path for legitimate users.

The boundary is essential: CAPTCHA and bot-management controls do not scrub volumetric traffic, add database capacity, fix a memory leak, or replace CDN, WAF, traffic-scrubbing, origin-resilience, and incident-response processes. Their role is narrower: reduce avoidable high-cost automated work before it reaches components already under pressure.

FAQ About DoS Attacks