Layer Cloudflare security controls

Cloudflare ships several security controls because no single rule can spot every harmful request. Each control looks at 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 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. Then watch the Security Events log, and only 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 a 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 can’t 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. My habit is to set a new rule to log first, read the matches for a few days, then switch it to block.

The edge does not know your business rules

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

Try this: take four cases, a network flood, a SQL injection attempt, a login spray, and an abusive checkout loop. For each one, pick the first control that should catch it, and name the application-level check that must stay in place even when the edge control works.