mgarden

Cloudflare WAF

4 min read

cloudflare waf owasp security claude-curated

Cloudflare’s Web Application Firewall inspects HTTP requests at the edge and applies managed rulesets, custom rules, and rate-limit rules. It evaluates rules in a defined phase order and either blocks, challenges, logs, or skips matching traffic. Functionally analogous to AWS WAF but bundled with Cloudflare’s reverse proxy.

OWASP Core Rule Set (CRS)

Cloudflare ships a managed implementation of the OWASP ModSecurity Core Rule Set — an open-source generic attack-detection ruleset (sponsored by OWASP). CRS uses an anomaly-scoring model rather than a one-rule-one-block model.

  • Each sub-rule that matches contributes a score to the request.
  • Once the cumulative score exceeds the configured threshold, a final rule blocks (or otherwise actions) the request.
  • This makes CRS resilient to evasion: no single signature has to be perfect.

Anomaly Score Model — Rule 949110

The terminating rule is 949110 — “Inbound Anomaly Score Exceeded”. It fires when:

TX:ANOMALY_SCORE >= TX:INBOUND_ANOMALY_SCORE_THRESHOLD

Default thresholds:

Paranoia LevelDefault Score Threshold
1 (least strict)5
25
35
4 (most strict)5

Higher paranoia levels add more (and more aggressive) sub-rules, increasing the chance any given rule contributes to the score. The threshold itself often stays constant; what changes is how easily traffic accumulates score.

Each contributing sub-rule is tagged critical (5), error (4), warning (3), or notice (2). A single critical match alone reaches the default threshold.

Sub-rule Categories

CRS organizes detections into rule files / categories:

CategoryRule RangeDetects
Method enforcement911xxxDisallowed HTTP methods
Scanner detection913xxxKnown scanners (sqlmap, nmap, nikto)
Protocol enforcement920xxx–921xxxMalformed requests, smuggling
Application attack — LFI930xxxLocal file inclusion
Application attack — RFI931xxxRemote file inclusion
Application attack — RCE932xxxCommand/code execution
Application attack — PHP933xxxPHP-specific injection
Application attack — XSS941xxxCross-site scripting
Application attack — SQLi942xxxSQL injection
Application attack — Session fixation943xxxSession attacks
Java attacks944xxxDeserialization, log4shell-class
Anomaly score blocking949xxxFinal scoring + block

See OWASP for context on the broader OWASP Top 10.

False-Positive Remediation

CRS is generic and will false-positive on legitimate application traffic (rich-text editors, file uploads, query strings containing SQL keywords, etc.). Remediation options, in order of preference:

1. Skip Rule by URL Pattern (Custom Rule with skip)

Best for surgical exemptions on specific endpoints.

(http.request.uri.path eq "/admin/wysiwyg" and http.host eq "app.example.com")
  -> Action: Skip
  -> Skip: Specific managed ruleset(s): OWASP CRS, Rules: 941100, 941110

2. Custom Rule Expressions

Use field-level filters to allow known-good payloads through before CRS runs:

(cf.client.bot or ip.src in $office_ips) -> Skip all managed rulesets

3. Disable Specific Rule IDs

Last resort — turns the rule off zone-wide. Loses all the detection value.

4. Lower Paranoia Level

Blunt instrument — disables many sub-rules at once. Acceptable as a starting point during rollout.

Managed Rulesets vs Custom Rules vs Rate-Limit Rules

TypeSourceMaintained ByPhaseTypical Use
Managed RulesetsCloudflare / OWASPCloudflarehttp_request_firewall_managedGeneric attack detection (CRS, exposed creds, sensitive data)
Custom RulesYouYouhttp_request_firewall_customApp-specific block/allow/challenge logic
Rate-Limit RulesYouYouhttp_ratelimitThrottling per IP / token / fingerprint

Custom Rules execute before Managed Rulesets, so they can skip managed rulesets for known-good traffic.

Best Practices

  • Start in Log mode, not Block. Run for at least one full traffic cycle (1–2 weeks) to surface false positives before enforcing.
  • Use Paranoia Level 1 to start; raise to 2 once clean. PL3+ requires significant tuning and is rarely justified for typical web apps.
  • Tag exemptions with descriptive rule names referencing a ticket — they will outlive memory of why they exist.
  • Layer custom rules above managed: e.g. enforce auth-required paths return 401 before CRS even sees the body.
  • Monitor false-positive rate via Security Events, not just block rate. Feed events into a SIEM or SOAR pipeline. See Monitoring Cloudflare Security Events.
  • Review rule list quarterly. CRS rule IDs and Cloudflare additions shift; old skip lists can mask new genuine threats.
  • Never disable rule 949110 — it’s the terminator. Tune the score-contributing sub-rules instead.

See also

References

Graph View