What Is DoS?

DoS, short for Denial of Service, is an attack that tries to make a system, application, or network service unavailable to legitimate users by exhausting resources, triggering failures, or disrupting normal processing. Unlike a distributed attack, a DoS attack can come from a single source or a limited origin point, but the business effect can still be serious.

If you are comparing related concepts, see what is ddos and what is botnet for useful context.

How DoS works

A DoS attack succeeds by exhausting something the target depends on. That could be bandwidth, CPU, memory, session capacity, database connections, or application-specific functions.

While the technical details vary, most DoS activity falls into a few common patterns.

Flooding a target with traffic

The attacker sends more traffic, requests, or packets than the target can handle. If enough traffic arrives from one source, the service may become slow or unavailable.

This can affect:

• Internet bandwidth
• Firewall or load balancer capacity
• Server CPU and memory
• Connection tables
• Application worker pools

Abusing expensive application functions

Not every denial-of-service attack requires massive traffic volume. Some attacks work by repeatedly calling functions that are expensive for the application to process.

Common examples include:

• Search endpoints
• Login forms
• Report generation
• File export features
• Database-heavy API queries
• Password reset functions

If a single source keeps triggering expensive operations, legitimate users may be locked out by resource exhaustion even without a large network flood.

Triggering software or protocol weaknesses

Some DoS attacks exploit how an application, service, or protocol handles repeated or malformed input. The result may include:

• Process crashes
• Memory exhaustion
• Thread starvation
• Service lockups
• Application instability

In these cases, the issue is not only traffic volume. It may be poor error handling, weak input validation, or fragile service design.

Consuming shared dependencies

A service may appear healthy at the web layer but still fail because backend dependencies are overwhelmed. Attackers may target:

• Database connections
• Cache layers
• Session stores
• Authentication systems
• Background job queues
• Third-party API dependencies

When one bottleneck is exhausted, the visible application can still go down.

DoS vs DDoS

The main difference between DoS and DDoS is the number of attacking sources.

DoS

A DoS attack usually comes from:

• One host
• One IP
• One origin point
• A small number of coordinated sources

DDoS

A DDoS attack uses many systems at once, often through a botnet or other distributed infrastructure.

The outcome can look similar from the victim’s perspective, but DDoS is usually harder to filter because the traffic is spread across many sources.

Common signs of a DoS attack

Teams often first notice DoS as a performance or availability problem rather than as a labeled security event.

Common signs include:

• Slow response times
• Repeated timeouts
• Failed logins or transactions
• Spikes in CPU, memory, or network usage
• Sudden instability in one application function
• Repeated requests from a single source
• Crashed or restarted services

Because these symptoms can overlap with ordinary outages, investigation usually requires both operations and security visibility.

When you’ll encounter DoS

You are most likely to encounter DoS in environments where service availability matters and exposed systems can be abused directly.

Public-facing websites and portals

Internet-accessible websites, login pages, customer dashboards, and support portals are common targets. If a single source can overload a critical function, the result may still be a meaningful outage.

APIs and application endpoints

Modern applications rely heavily on APIs. A single abusive client can sometimes trigger repeated expensive requests, especially if the API lacks strong throttling, caching, or queue protections.

Application performance incidents

Sometimes the first sign of DoS is simply that an application becomes unstable under unusual traffic patterns. Security and engineering teams may later determine that a single source caused the problem intentionally.

Internal services

DoS is not limited to public systems. Internal services can also be disrupted if a compromised host, insider, or poorly controlled internal client overwhelms shared resources inside the environment.

SMB and mid-market environments

Smaller organizations may not have large-scale mitigation layers, which means even modest denial-of-service activity can have a visible effect. In these environments, DoS may first appear as:

• “The site is down”
• “The VPN is unusable”
• “The app keeps timing out”
• “Only one feature is broken under load”

How teams defend against DoS

DoS resilience is partly a security problem and partly an architecture problem. The best defenses depend on the type of service being protected, but common controls include:

Rate limiting

Rate limiting restricts how often a client, account, or IP can make requests in a given time window. It is one of the most useful controls against application-layer denial-of-service.

Caching and load distribution

Caching can reduce pressure on backend systems, while load balancing can spread traffic across multiple nodes. These controls improve resilience, even if they do not eliminate all DoS risk.

Input validation and application hardening

Applications should handle abnormal or malformed input safely. Weak error handling and fragile workflows make denial-of-service easier.

Monitoring and alerting

Good observability helps teams spot spikes in:

• Request volume
• Error rates
• Backend latency
• Session usage
• CPU and memory consumption

The faster teams can identify abnormal patterns, the faster they can respond.

Upstream filtering and provider support

For public services, CDNs, hosting providers, edge security tools, and network filtering services can help absorb or block abusive traffic before it reaches the origin.

Practical note for smaller teams

Smaller teams usually get more value from basic resilience improvements than from chasing every advanced mitigation feature at once. Start with strong rate limiting, simple monitoring, CDN or hosting protections, and careful review of expensive application endpoints.

If your team frequently administers sites, dashboards, or cloud tools from public networks, a reputable VPN such as Try Proton VPN → or Check NordVPN pricing → may also help reduce exposure during remote admin sessions. That will not stop DoS attacks against your public services, but it can still support safer operational access for the people managing them.

Conclusion

DoS is a denial-of-service attack that aims to make a system unavailable by overwhelming resources or breaking normal service behavior from a single source or limited origin point. Even without a large botnet, the impact can be real if the targeted system has weak controls or fragile dependencies.

For defenders, the key is not only blocking bad traffic but designing services that fail more gracefully under stress. Rate limiting, resilient architecture, strong monitoring, and fast operational response all matter.