DDoS protection basics for small sites and shops
DDoS attacks are not just a problem for banks and game studios — small sites get caught in the blast radius constantly. How they work, and what to actually do when one starts.
The first sign is almost never a security alert. It is the site being slow, then the site being very slow, then the hosting dashboard showing CPU pinned at 100% and a support ticket that says "have you been running a campaign?"
By the time anyone uses the word DDoS, it has usually been going for twenty minutes. So it is worth understanding the shape of the thing before you meet one — particularly the fact that there are two quite different attacks hiding under the same acronym, and they need different responses.
Why "distributed" is the whole problem
DDoS stands for Distributed Denial of Service. The denial-of-service part is simple: overwhelm a site so real visitors cannot get in. The distributed part is what makes it hard to deal with.
The traffic does not come from one place you can block. It comes from thousands of compromised devices spread worldwide — home routers, security cameras, servers with weak passwords, often owned by people with no idea they are participating. Each sends a trickle. Together they are a firehose, and there is no single IP address to drop.
Two attacks, two problems
Volumetric floods
The brute-force version: send more raw traffic than your connection can carry. These are measured in gigabits per second, they frequently use amplification — sending a small forged request to a service that replies with a much larger response aimed at you — and they do not care what your website is or does. Your pipe fills up and legitimate packets have nowhere to go.
The important thing to understand is that you cannot solve this at your server. If someone is sending 50 Gbps at a 1 Gbps connection, nothing running on the far end of that connection matters. The traffic has to be absorbed upstream, in a network with more capacity than the attack.
Application-layer floods
The sneakier version, and increasingly the more common one against small sites. Rather than raw volume, these send requests that look legitimate but are expensive for you to answer: search queries with unusual terms, endpoints that trigger a heavy database join, a login form, anything uncacheable.
The traffic volume can be modest — a few thousand requests a minute, nothing that would trouble your bandwidth — while your database melts. A shop with a slow search endpoint can be taken down by an attack small enough that nobody's monitoring alerts on the bandwidth at all.
| Volumetric | Application-layer | |
|---|---|---|
| Measured in | Gigabits per second | Requests per second |
| What it exhausts | Your bandwidth | Your CPU and database |
| Looks like | Obvious garbage | Plausible requests |
| Stopped by | Upstream capacity | Rate limits, caching, challenges |
| Can your server help? | No | Partly |
Why small sites get hit at all
Who would attack a small site?
- Extortionists — a short demonstration, then a payment demand
- A competitor, usually around a sale or launch
- Someone testing a booter service on a random target
- Collateral damage from an attack on a neighbour at your host
Why it hurts more
- One server has a hard ceiling and no elasticity
- Downtime during a promotion is directly lost revenue
- Shared hosting neighbours can take you down with them
- Nobody is on call at 2am
That last point in the left column is worth dwelling on. On shared hosting, an attack aimed at a completely unrelated site on your server can take yours offline too. You do not have to be a target to be a casualty.
The defence is capacity you do not own
You cannot win a capacity fight from a single server, and buying a bigger server does not change the arithmetic — the attacker can add bots faster and more cheaply than you can add hardware.
What works is putting a large distributed network in front of you. An edge network has points of presence in many cities, each with substantial capacity, and traffic is absorbed and filtered across all of them rather than converging on your one box. A flood that would flatten a single origin arrives at fifty locations at once, gets filtered at each, and what reaches you is whatever was legitimate.
Caching does a surprising amount of work here too. If 95% of requests are answered from the edge, an application-layer flood aimed at cacheable URLs is absorbed entirely — the attacker is DDoSing a cache, which is what caches are for.
None of this helps if your real origin IP is public. Attackers look it up — in old DNS records, in mail headers, in certificate transparency logs — and hit it directly, bypassing your protection entirely. Change the origin IP when you move behind an edge network, and configure it to accept traffic only from the edge.
What to do while it is happening
Confirm what kind it is
Bandwidth saturated, or CPU saturated with modest bandwidth? That single question decides everything you do next.
Do not start blocking countries in a panic
It feels decisive, it usually blocks customers, and the attack simply moves. Reach for it late, not first.
Turn caching up
Raise TTLs and cache aggressively, including things you would normally leave dynamic. A stale page beats no page.
Put a challenge on the expensive endpoints
Search, login, anything uncacheable. A proof-of-work challenge costs a real browser nothing and makes automated volume uneconomic.
Check your origin is actually hidden
If traffic is still arriving directly, nothing at the edge can help you. Firewall the origin to the edge network's ranges.
Write down what happened
Afterwards, while it is fresh. Attacks recur, often from the same people, and the second time is much calmer if you have notes.
Frequently asked questions
What is a DDoS attack?
A DDoS, or distributed denial of service, attack floods a website with traffic from thousands of separate compromised devices so that legitimate visitors cannot get through. Because the traffic originates from many sources at once rather than one, there is no single address to block, and the total volume can far exceed what a single server or connection can handle.
Can a small website be hit by a DDoS attack?
Yes, and it happens regularly. Small sites are targeted by extortionists seeking a quick payment, by competitors around sales and launches, and by people testing attack services on arbitrary targets. On shared hosting a site can also be taken offline as collateral damage from an attack aimed at an unrelated neighbour on the same server.
How do I stop a DDoS attack?
You cannot stop one from the server being attacked — a volumetric flood saturates the connection before anything on your server runs. The effective approach is to sit behind a distributed edge network that absorbs and filters traffic across many locations, cache aggressively so most requests never reach your origin, apply rate limits and challenges to expensive endpoints, and ensure your origin IP is hidden and accepts traffic only from the edge.
What is the difference between volumetric and application-layer DDoS?
A volumetric attack aims to exhaust your bandwidth with sheer traffic volume, measured in gigabits per second, and must be absorbed upstream of your connection. An application-layer attack sends a much smaller number of requests that are individually expensive to serve — heavy searches, uncacheable pages, login attempts — exhausting CPU and database capacity rather than bandwidth, and is mitigated with caching, rate limiting and challenges.
Does a CDN protect against DDoS?
Substantially, for both types. A CDN's distributed capacity absorbs volumetric floods that would overwhelm a single origin, and its cache answers most application-layer requests without involving your server at all. The protection only holds if your origin IP is hidden and firewalled to accept traffic only from the CDN — otherwise attackers can bypass it by targeting the origin directly.
Should I block countries during a DDoS attack?
It is usually the wrong first move. Country blocks feel decisive but reliably block real customers, and a distributed botnet simply shifts to sources in permitted countries. Caching more aggressively, rate limiting expensive endpoints and applying challenges to suspicious traffic are more precise and less costly. Treat geographic blocking as a late-stage measure, and review it once the attack ends.
The uncomfortable truth about DDoS is that the preparation has to happen before the attack, because there is not much you can usefully do from inside one. The good news is that the preparation is short: sit behind a network with capacity, hide your origin, and cache enough that most of your traffic never touches a server at all.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
