Cloudflare Rule Order: Why Security Rules Can Silently Fail

You set up a Cloudflare WAF rule to block access to /metrics. Then you add a Managed Challenge rule to protect your entire site from bots. Everything looks correct in the dashboard. But attackers can still reach your Prometheus metrics endpoint. What went wrong?

The Problem: Terminating Actions

Cloudflare evaluates rules in order, but certain actions stop evaluation immediately. These are called terminating actions:

• Interactive Challenge
• JS Challenge
• Managed Challenge
• Block
• Redirect
• Serve Error

When a request triggers a terminating action, Cloudflare stops processing all remaining rules. If your Block rule comes after a Challenge rule, it never executes once the challenge is passed.

Quick Reference

# Correct rule order (most restrictive first)
1. Skip        - Whitelist trusted IPs
2. Block       - Deny access to sensitive paths
3. Log         - Capture traffic for analysis
4. Redirect    - URL redirections
5. Challenge   - Bot detection (last)

How the Bypass Works

Consider this common misconfiguration:

Rule 1: Managed Challenge → all requests
Rule 2: Block → /metrics endpoint

A user visits your site and completes the challenge. Cloudflare sets a cf_clearance cookie. On subsequent requests, the cookie clears the challenge automatically, terminating rule evaluation at Rule 1. Rule 2 never runs, and /metrics remains exposed.

The Fix: Reorder Your Rules

Security-critical Block rules must come before any Challenge rules:

Rule 1: Skip → trusted monitoring IPs
Rule 2: Block → /metrics, /admin, /debug
Rule 3: Block → malicious patterns
Rule 4: Managed Challenge → all requests

This ensures Block rules execute first. Only after passing all Block checks does the request reach the Challenge layer.

Recommended Rule Order

Group your Cloudflare rules by action type:

Priority	Action	Purpose
1	Skip	Whitelist known services
2	Block	Deny access to sensitive resources
3	Log	Capture traffic before modifications
4	Redirect	URL rewrites and redirections
5	Challenge	Bot detection and rate limiting

Verify Your Configuration

Check your current rule order in the Cloudflare dashboard:

1. Navigate to Security > WAF > Custom rules
2. Review the rule sequence from top to bottom
3. Ensure all Block rules appear before Challenge rules
4. Test with curl both with and without cookies

# Test without clearance cookie
curl -I https://example.com/metrics

# Test with clearance (simulating passed challenge)
curl -I -b "cf_clearance=abc123" https://example.com/metrics

Terraform and API Users

If you manage Cloudflare with Infrastructure as Code, verify your rule positions explicitly:

resource "cloudflare_ruleset" "security" {
  rules {
    action = "block"
    expression = "(http.request.uri.path contains \"/metrics\")"
    # Position matters - lower numbers execute first
  }
}

Conclusion

Cloudflare rule order is not intuitive. The dashboard suggests rules execute in sequence, but terminating actions break that expectation. Always place Block rules before Challenge rules, and verify your configuration handles the cf_clearance cookie scenario.

This is exactly the kind of subtle misconfiguration that slips through code reviews and security audits.

---

Catching configuration drift and security misconfigurations before they reach production is challenging. Akmatori helps SRE teams build intelligent agents that monitor infrastructure and flag policy violations automatically.