How do you configure Cloudflare to protect a website from DDoS?

Question

IT Interview Practice · Accepted Answer

**Cloudflare protects a website best when requests pass through it and the application can handle the traffic that remains.** Turning on one setting does not protect every path to your server.

Imagine an online shop. Attackers might flood product images, repeatedly call an expensive search endpoint, or contact the server directly. These consume different resources, so the setup needs several layers.

## 1. Put Cloudflare in the request path

Enable the proxied status for the website's supported DNS records. Visitors then reach Cloudflare before the origin, which is the server actually running your website. A DNS-only record provides name resolution; it does not send the website's HTTP traffic through this protection path.

```text
Browser -> Cloudflare -> Origin -> Database
```

This is the foundation: filtering at Cloudflare helps only for requests that reach it. Check every public hostname used by the shop, including the API hostname, rather than checking the main domain alone.

## 2. Close the direct route to the origin

If attackers can still reach the origin directly, they can bypass the filtering. Restrict public web ingress to the appropriate Cloudflare IP ranges and keep those ranges updated. Alternatively, evaluate Cloudflare Tunnel, which connects outward and can remove the need for public inbound web ports.

Keep administrative access on a separate protected route and databases off the public internet. Test both normal access through Cloudflare and rejection of direct access. Merely hiding an IP address is insufficient. See [origin protection](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/).

## 3. Filter attacks while preserving real customers

Review the managed DDoS protection and the controls available on your plan. Add appropriate WAF rules: a WAF checks HTTP requests for suspicious patterns before forwarding them. DDoS protection and WAF rules address overlapping but different problems; neither proves that every accepted request is cheap for your application.

Start with rules you can explain, inspect the affected traffic, and adjust narrowly if legitimate customers are blocked. A large blocked-request count is not itself a success metric. Cloudflare documents its [DDoS setup and tuning](https://developers.cloudflare.com/ddos-protection/get-started/).

## 4. Protect expensive operations separately

A request for a cached image is usually much cheaper for the origin than a search that scans many database records. Apply rate limits to costly endpoints based on normal usage and the capacity of the service behind them.

- For login or OTP delivery, combine edge limits with application limits by account or destination. A single IP can represent many real users.
- For search or report generation, bound the work each request can trigger; limiting request count alone may leave expensive requests dangerous.
- For authenticated APIs, consider the customer or API key as well as network signals. Distributed attackers can use many IP addresses.

There is no universal safe threshold. Observe legitimate peaks, introduce limits carefully, and measure both backend relief and rejected valid requests.

## 5. Use caching where sharing is safe

Cache public images and static files so repeat requests can be served without reaching the origin. For our shop, this reduces the resources spent repeatedly serving the same product image.

Personal carts and account pages require different rules because users must not receive someone else's data. Review cache keys and bypass conditions before caching dynamic responses. Caching reduces repeated work; it does not make login or checkout automatically safe under load.

## 6. Use emergency challenges with a recovery plan

Under Attack mode can introduce a browser challenge during an incident. Evaluate it for the affected browser routes and remove the temporary measure when appropriate. Machine clients and payment webhooks may not complete browser challenges, so their routes need suitable authentication and targeted controls.

Finally, verify that real customers can browse and complete checkout while monitoring origin latency, CPU, database pressure and errors. If a direct network attack saturates the origin's connection, coordinate with the hosting provider for upstream protection. The goal is continued useful service, not a promise that no attack can cause disruption.

1. Put Cloudflare in the request path

2. Close the direct route to the origin

3. Filter attacks while preserving real customers

4. Protect expensive operations separately

5. Use caching where sharing is safe

6. Use emergency challenges with a recovery plan

Related questions