Quick answer: If your site is behind Cloudflare, you can stop most attack traffic at the edge before it ever reaches the origin. The priority order is: first hide the origin (nginx open only to Cloudflare IPs, ideally a tunnel), then enable WAF managed rules (Cloudflare Managed plus OWASP Core), then bot management (Super Bot Fight Mode), and add rate limiting on critical paths (login, API, admin). During an intense wave, Under Attack Mode puts a JavaScript challenge on every request and instantly eliminates most automated scanners; but because it burdens real users and SEO, step it down to Managed Challenge once the wave passes. With the right configuration, routine bot scanning never bothers you.

Every internet facing site receives automated scanning and bot traffic from the moment it goes live. Most of the time this is not an attack but the background noise of the internet; but if the configuration is weak, that same noise burdens the origin server and can even enable a real attack. This guide explains, from an expert perspective, how to harden a site behind Cloudflare at the edge, which setting to enable when, and the most common mistakes.

Layered defense: hide the origin first

The most critical principle is that the origin server must not be directly reachable from the internet. A common weakness of sites behind Cloudflare is that the origin IP leaks and the attacker bypasses Cloudflare entirely to hit the server directly (CDN bypass). Three measures are taken together against this.

First, nginx or the web server must accept connections only from Cloudflare's published IP ranges and reject everything else. Second, the real client IP must be restored from the Cloudflare header (CF-Connecting-IP) so logs and ban decisions see the correct IP. Third, the most robust method is to use Cloudflare Tunnel and leave no public port (80/443) open on the server; then reaching the origin directly becomes architecturally impossible. We covered server side hardening in detail in our Linux server hardening CIS article.

WAF managed rules: cut known attacks by signature

Once the origin is hidden, the second layer is the Web Application Firewall. Cloudflare's managed rule sets block known exploit patterns (SQL injection, path traversal, known CVE exploitation, common scanner signatures) before the request even reaches the origin.

What to enable: the Cloudflare Managed Ruleset and the OWASP Core Ruleset. The OWASP set has a sensitivity (paranoia) level and a score threshold; too high a sensitivity produces false positives and can block legitimate requests, so in production it is raised gradually while logs are watched. The WAF is the first curtain against application layer flaws but is not sufficient alone; the real fix is in the code. We examined the source code side of application flaws in our SAST, DAST, IAST and SCA selection matrix article.

Bot management and Under Attack Mode

Most scanning traffic is bots. Cloudflare bot management separates automated requests from legitimate users using browser fingerprinting and behavior analysis.

Level What it does When
Bot Fight Mode challenge/block known bad bots can stay on always
Super Bot Fight Mode categorically manage definite/unverified bots when bot traffic is heavy
Managed Challenge a light, auto solved challenge for suspicious requests normal protection level
Under Attack Mode JavaScript challenge on EVERY request during an active intense wave

The critical distinction is this: Under Attack Mode is an emergency switch, not a permanent setting. Because it puts a "Just a moment" interstitial on every request, it instantly eliminates automated scanners but slows real users and can hurt SEO by burdening search engine bots too. When the intense wave passes, step down to Managed Challenge or security level "High". Also, if you enable Under Attack across the whole zone, the subdomains you use for SSH or management will get caught by the challenge and can cut off your access; in that case you need to exempt that subdomain from the challenge with a configuration rule.

Rate limiting: cut brute force and scraping

Rate limiting restricts excessive requests arriving at a given path in a short time. The paths most in need of protection are login, authentication and API endpoints; these are targets for brute force, credential stuffing and data scraping.

Practical configuration: put a low threshold per minute on /login (for example 5 to 10 requests) and block when exceeded; define a reasonable general limit for /api/*. Edge rate limiting is applied at Cloudflare before the request reaches the origin, so brute force never burdens your server. We covered the logic of account takeover attacks and additional measures in our account takeover and recovery article, and the API side rate limit in our API rate limiting and bot management article.

DDoS and volumetric attacks

Cloudflare's automatic DDoS protection (L3/L4 network level and L7 application level) mitigates most volumetric attacks by default. In addition, the sensitivity of the HTTP DDoS managed ruleset can be raised, and temporary block rules can be defined for the specific ASN or countries the attack comes from. We described DDoS attack types and the general mitigation approach in detail in our what is a DDoS attack and protection article. The important point is that DDoS protection is meaningful while the origin is hidden; if the origin IP has leaked, the attacker bypasses Cloudflare and hits directly.

The most common mistakes

In the field we most often see these mistakes. The origin IP leaking from old DNS records, email headers or certificate transparency logs and staying open to CDN bypass. Under Attack Mode left permanently on, breaking SEO and user experience. WAF false positives not being watched and legitimate traffic being silently blocked. Management subdomains (ssh, vpn) getting caught by a zone wide challenge and cutting off access. Rate limiting only being defined but not actually applied to the relevant path. Each of these leaves a silent gap even in a panel that looks correct.

The KAOS and DSET approach

At DSET, when hardening a site behind Cloudflare we first verify that the origin is genuinely unreachable (a CDN bypass test via DNS, certificate transparency logs and a direct IP attempt), then build the WAF, bot and rate limiting layers. The KAOS tool we develop therefore looks for origin leakage and edge weaknesses first on every scan, because even the best WAF cannot save a leaked origin IP. We verify the configuration with measurable controls, without inflated promises. To build your site's edge defense or harden it after an attack, contact DSET with our team at Ankara Hacettepe Teknokent. For WordPress based sites our enterprise WordPress hardening article also helps.

Frequently asked questions

Can I leave Under Attack Mode on all the time? Not recommended. Under Attack Mode puts a JavaScript challenge on every request; it eliminates automated scanners but slows real users and can hurt SEO by burdening search engine bots. Turn it on only during an active, intense attack wave; once it passes, Managed Challenge or security level "High" is enough. Also, if you enable it zone wide, your management subdomains can get caught by the challenge too.

I use Cloudflare, can my origin IP still leak? Yes. The origin IP can leak from old DNS records, outgoing email headers, certificate transparency logs or misconfiguration. If it leaks, the attacker can bypass Cloudflare entirely and hit the server directly (CDN bypass). That is why it is essential to open nginx only to Cloudflare IPs or to leave no public port at all with Cloudflare Tunnel.

Why do some legitimate requests get blocked when I enable the WAF? The OWASP Core Ruleset can produce false positives at high sensitivity. In production, raise the sensitivity gradually, watch the WAF event logs, and define exception (skip) rules for legitimate paths blocked by mistake. Cranking sensitivity blindly to the maximum creates an availability problem instead of security.

Sources