DDoS Protection Explained: What Your Website Needs Before an Attack

Protect a website from DDoS by placing sufficient capacity and filtering in front of the origin, hiding or locking down direct origin access, separating network and application controls, and rehearsing the response. Configure protection before an attack. During an attack, the team should be executing a known playbook, not deciding who owns DNS, what can be rate limited, or whether a provider certificate is valid.

DDoS means distributed denial of service: many sources or distributed infrastructure overwhelm a service's network, transport, protocol, or application resources. The traffic can be volumetric, such as UDP or TCP floods; protocol-focused, such as SYN exhaustion; or HTTP-layer traffic that looks like ordinary requests but consumes expensive application work. These layers can overlap, and a site needs controls that match the protected asset.

Choose the right protection layers

Layer 3 and 4 protection absorbs or filters network and transport floods before they consume your transit, firewall, load balancer, or server connections. A globally distributed edge, Anycast network, upstream scrubbing service, or transit provider may be required for large attacks or non-HTTP protocols.

Layer 7 protection analyzes HTTP behavior such as request rate, path, method, response cost, headers, and client signals. It can protect a login or search endpoint from an application-layer flood, but a simple global request limit may block real customers during a legitimate peak. Layer 7 controls need route-aware thresholds and a baseline of normal traffic.

Application resilience reduces the damage of traffic that passes the perimeter. Cache public content, bound expensive queries, use queues, protect database connections, apply per-identity rate limits, and make writes idempotent. A DDoS provider cannot correct an application that performs unbounded work per request.

Cloudflare provides automatically enabled DDoS managed rulesets for supported web zones and separate products for broader IP, TCP, UDP, and network protection. Fastly can combine edge delivery, shielding, health checks, rate controls, and its security products, but the correct service depends on whether the protected asset is HTTP, TCP, UDP, DNS, or a private network. Confirm plan limits, protocols, mitigation scope, logging, escalation, and commercial terms with the provider before relying on them.

Prepare the architecture

1. Map the public surface. Inventory DNS records, hostnames, IPs, ports, APIs, mobile endpoints, origin services, third-party dependencies, and non-HTTP protocols. Search historical DNS and certificate data for old origin names and addresses. Remove unused records and restrict administrative interfaces.

2. Put public web traffic behind the edge. Proxy the intended web and API hostnames through the protection layer. Use TLS to the origin, validate the expected host and SNI, and keep certificates current. Do not publish a DNS-only record that points at the same origin unless it is intentionally protected by another path.

3. Lock down the origin. Allow only the IP ranges or authenticated connections of your trusted edge providers and operational systems. Cloudflare equivalents include proxied records, current Cloudflare IP allowlists, and Authenticated Origin Pulls using client certificates. A simple IP allowlist is useful but must be maintained; mTLS offers stronger proof of the edge-to-origin relationship. If multiple CDNs are active, authorize each one and test the policy during failover.

4. Separate policy by endpoint. Public pages, login, search, checkout, APIs, webhooks, and administration need different rate and challenge behavior. Protect machine-to-machine callbacks with authentication and signatures rather than browser challenges. Cache safe public responses so attack traffic does not force an origin computation for every request.

5. Set safe failure behavior. Define what the site serves when the origin is slow, an upstream dependency fails, or suspicious traffic spikes. A static status page, cached catalog, queue, or disabled recommendation feature may preserve the primary customer path. Do not serve stale private data or hide an authorization failure behind a generic fallback.

Build the response plan

Write a short runbook with the incident commander, network and application owners, security contact, provider escalation path, communications lead, and decision authority. Include account IDs, zone or service names, emergency access, current origin addresses, provider IP-range links, and the steps to change a rule. Store break-glass credentials securely and test that the right people can use them.

Define triggers and actions. Examples include a sudden rise in packets or bandwidth, a regional error spike, a high rate of expensive HTTP requests, origin connection exhaustion, or a provider mitigation alert. The first action may be verification and evidence collection, not an aggressive block. Preserve request samples, timestamps, headers, attack fingerprints, affected routes, and mitigation IDs while respecting privacy and retention requirements.

For Cloudflare, the DDoS managed rulesets and alerts provide a baseline, and overrides can tune sensitivity or actions for defined traffic. Cloudflare's own guidance recommends analyzing flagged traffic and adjusting rules carefully when validating possible false positives. On Fastly, use service logs, health state, shielding, rate controls, and security telemetry appropriate to the product configuration. In both cases, use log or non-destructive observation where available before changing a broad action, and never disable baseline protection to troubleshoot a single client.

Test before an attack

Run a tabletop exercise that walks through detection, escalation, provider contact, rule changes, origin isolation, customer communication, evidence handling, and recovery. Then test the technical path with an approved provider or specialist. Do not generate a large attack against production or an unconsenting network. A safe test can validate DNS, TLS, firewall allowlists, health checks, rate limits, cached fallback, dashboards, and rollback without creating harmful traffic.

Exercise failover and recovery. Confirm that all active CDNs can reach the origin, that the origin trusts their connections, that purge and cache policy remain consistent, and that traffic returns gradually after the event. Watch for a thundering herd when cached content expires or when clients retry simultaneously. Record recovery time, customer impact, false positives, provider response time, and every manual step that should be automated or documented.

Observe both the attack and the business. Track bandwidth, packets, connections, requests per second, status codes, cache status, WAF actions, rate-limit actions, origin CPU, database connections, queue depth, latency, and conversion or transaction success. Alert on changes from the established baseline by region and route, not just total traffic.

Mistakes include assuming a CDN protects an unproxied hostname, allowing direct origin access, using one rate limit for every route, blocking an entire country as a first response, challenging webhooks, relying on a status page instead of telemetry, testing only the happy path, and having no post-incident review. The DDoS protection guide covers the managed edge layer; pair it with the WAF guide and a resilient CDN.

For current platform concepts, see Cloudflare DDoS Protection and Cloudflare Authenticated Origin Pulls. For incident preparation, use NIST SP 800-61 Rev. 3. Contact Optimi to review your edge and response plan before it is needed.

There are only two hard things in Computer Science: cache invalidation and naming things.