Layer Cloudflare security controls

Cloudflare ships several security controls because no single rule can identify every harmful request. Each control sees a different signal.

DDoS protection absorbs volume. It reacts to traffic patterns, not request content, and it is always on for proxied zones. WAF rules inspect individual application requests for attack payloads. Rate limiting counts repeated actions from one client. Bot products add signals about whether traffic looks automated.

The layers answer different questions. “Is this a flood?” is not the same question as “does this request contain SQL injection?” or “has this IP tried to log in 200 times?”

Start with managed rules and evidence

Cloudflare maintains managed WAF rulesets that cover common attack payloads. Turn those on first, watch the Security Events log, and only then write custom rules based on what your real traffic shows.

A custom WAF rule uses the Rules language:

(http.request.uri.path contains "/wp-admin" and not ip.src in {203.0.113.0/24})

A rate limiting rule targets repetition instead of content — for example, more than 10 requests to /login from one IP in one minute triggers a block or a challenge.

Blocking has a cost too

A challenge or block can also reject good users, API clients, accessibility tools, or your own uptime monitoring. A challenge page is meaningless to a JSON API client: it cannot solve it, so it just fails.

Test the failure side:

curl -i https://api.example.com/orders
# HTTP/2 403
# cf-mitigated: challenge

If your monitoring sees this after a new rule, the rule is too broad. Prefer logging a new rule first, reading matches for a few days, then switching it to block.

The edge does not know your business rules

Keep application validation and authorization in your code. Edge controls filter recognizable abuse, but they do not know which user may access which resource. A request that passes the WAF is not “trusted” — it just did not match a known attack pattern.

Now classify these four: a network flood, a SQL injection attempt, a login spray, and an abusive checkout loop. Choose the first control that should catch each one, and name the application-level check that must remain even when the edge control works.