WAF Rules at the CDN Edge: OWASP Core Rule Set and Custom Policies

Deploying a Web Application Firewall at your origin feels safe until you realize every malicious request has already traversed your backbone, consumed TLS handshake resources, and hit your autoscaling group. Moving WAF enforcement to the CDN edge flips that model. You inspect and drop traffic within 20-50ms of the attacker, before it ever touches your infrastructure. In my experience running edge WAFs for high-traffic e-commerce and SaaS platforms, the shift is less about adding security and more about changing where your security budget is spent — in edge CPU cycles and rule tuning time, instead of origin capacity and incident response. This article breaks down how the OWASP Core Rule Set (CRS) actually behaves at the edge, and how to layer custom policies that close the gaps without drowning your team in false positives.

Why Moving WAF Enforcement to the Edge Changes Your Security Economics

An origin-deployed WAF sees clean, reassembled HTTP after your CDN has terminated TLS, normalized the request, and potentially cached the response. An edge WAF sees the raw, messy internet. That is both its power and its complexity. At the edge, you can enforce rules before any origin routing decision, which means you can block a Log4Shell probe, a SQL injection payload in a query string, and a 10,000 RPS credential stuffing wave without waking up your origin.

The economics are straightforward. I have measured origin load reduction of 12-18% just by blocking OWASP CRS critical anomalies at the edge on a typical retail property during peak. That traffic is not just malicious — it is wasteful. Every blocked request at the edge saves a full TLS termination, a WAF inspection at origin, application logic execution, and database connection attempts. When you are paying per-request for compute at origin and per-gigabyte for origin egress, blocking at the edge directly reduces your bill.

But edge enforcement also introduces constraints you do not face at origin. Edge workers and WAF engines have strict CPU time limits, typically 1-5ms per request for rule evaluation. Memory is limited. You cannot perform deep body inspection on a 10MB file upload without causing latency or buffering issues. And crucially, you often lose some fidelity in protocol parsing. The edge must make decisions on streaming data. Understanding these trade-offs is essential. If you treat an edge WAF like an origin ModSecurity install, you will create latency and false positives. If you design for the edge, you get the performance and protection benefits without the operational pain.

Edge WAFs also give you geographic leverage. A rule that blocks an attacker in Singapore at the Singapore PoP prevents that request from ever crossing the Pacific to your US-East origin. Combine this with Origin Protection: IP Whitelisting, Authenticated Pulls and Origin Cloaking and you create a true defense-in-depth model: the edge drops 99% of automated attacks, and the origin only accepts connections that are cryptographically proven to come from your CDN.

Deconstructing the OWASP Core Rule Set for CDN Deployment

The OWASP Core Rule Set is not a single firewall. It is a collection of over 200 rules organized into attack families, built originally for ModSecurity-compatible engines. When CDN vendors say they offer "OWASP CRS managed rules," they mean they have ported and optimized a subset of these rules to run on their proprietary edge engine. In my experience, no CDN implements 100% of CRS verbatim. They adapt.

Request Phases and Rule Families You Will Actually Encounter

CRS organizes rules into paranoia levels and phases. At the edge, phases are critical because you may not have access to response bodies or full request bodies. Most edge implementations focus heavily on request phases:

Request Header & Method (920xxx): Protocol violations, missing User-Agent, invalid HTTP methods. These are cheap to evaluate and highly effective at the edge. I enable these globally with almost no tuning.

Request URI & Args (941xxx - XSS, 942xxx - SQLi): These are your workhorses. They inspect query strings, parameters, and URIs for injection payloads. At the edge, these rules often run against normalized URIs. Be aware that double-encoding and path normalization differs between CDNs.

Request Body (921xxx, 932xxx, 933xxx): PHP injection, RCE, and application attack rules that inspect POST bodies, JSON payloads, and XML. This is where edge limitations appear. Many edge WAFs only inspect the first 8KB-128KB of a body by default to avoid buffering. If you have API endpoints that accept large JSON payloads, you need to verify your provider's body inspection limit.

Rules like 949xxx (Inbound Blocking) are meta-rules that aggregate anomaly scores. This scoring model is the heart of CRS and it behaves differently at the edge than in a traditional deployment.

What Gets Lost in Translation to Edge Engines

When a CDN ports CRS, they must rewrite rules from SecLang (ModSecurity syntax) into their own engine — often Rust, Go, or Lua-based. I have found three common gaps:

First, transformation functions. CRS relies heavily on transformations like t:lowercase, t:urlDecodeUni, t:removeNulls, and t:normalizePath. Not all edge engines support every transformation in the same order. A payload that is caught by rule 941100 at origin might bypass the edge if the edge does not perform the same URL decoding sequence. Always test with encoded payloads.

Second, libinjection and advanced pattern matching. Some edge providers replace CRS regex with their own ML-based SQLi/XSS detection for performance. It is faster but can have different false positive rates.

Third, response rules (950xxx-959xxx) are almost never available at the edge, because the edge does not buffer and inspect the origin response body for data leakage. If you need response inspection for credit card leakage or error disclosure, that still needs to happen at origin or via a dedicated outgoing inspection layer.

According to the HTTP Working Group Specifications, edge intermediaries are allowed to normalize requests in ways that can obscure attack payloads if the WAF engine does not account for it. Your edge WAF must parse HTTP with the same strictness as your origin application, or you create a parsing differential that attackers exploit for request smuggling and WAF bypasses.

Tuning Paranoia Levels and Anomaly Scoring Without Breaking Production

This is where most teams break their site. They enable CRS at Paranoia Level 2 or 3 in blocking mode on day one and then spend a week reverting. I have learned to treat CRS tuning as a data-driven, phased rollout, not a switch.

Understanding Anomaly Scoring vs. Self-Contained Blocking

CRS offers two operating modes. In self-contained mode, each rule blocks independently. In anomaly scoring mode (the default and recommended mode), each rule adds to an anomaly score, and blocking only occurs when the total score exceeds a threshold for that paranoia level. Anomaly scoring is far superior at the edge because it tolerates the noise of the internet.

For example, a request might trigger rule 920320 (Missing User-Agent) for 5 points and rule 941160 (XSS Filter - NoScript) for 5 points, for a total of 10. If your blocking threshold is 5 (critical), you block. If it is 10, you might only log. This prevents a single aggressive regex from taking down legitimate traffic that happens to contain the word "select" in a blog comment.

At the edge, I always start with anomaly scoring, threshold at 10-15 for blocking, and run in log-only (or "simulate") mode for at least 72 hours across a full business cycle. You need to see weekday API traffic, weekend user behavior, and marketing campaign parameters.

Finding Your Initial Paranoia Level

Paranoia Level defines rule aggressiveness. Higher levels add more strict, and more false-positive-prone, rules.

In my experience, PL1 in anomaly scoring mode is the correct global default for 80% of properties. I have seen teams successfully run PL2 globally, but only after 2-3 weeks of exclusion tuning and with strong observability. PL3 and PL4 should be scoped to specific paths like /api/admin/* or /wp-login.php if you use them at all. The CDN edge is not the place to be paranoid about every possible payload variant — it is the place to be efficient and accurate for the majority of attacks.

When you do increase paranoia, do it per-path. Most edge WAFs allow you to attach different rule groups to different URL patterns. Use that. Your marketing site at /blog/* does not need PL2 SQLi rules; your GraphQL endpoint at /graphql absolutely does.

Writing Custom Edge WAF Policies That Actually Survive Traffic Spikes

Managed CRS rules catch known attack classes, but they do not know your application. Custom policies are where you encode your business logic into the edge. The best custom rules I have written came directly from incident post-mortems or from manual log review, not from a theoretical threat model.

Pattern Matching Beyond CRS: Protecting Application-Specific Logic

CRS knows what a generic SQL injection looks like. It does not know that your application has an account_id parameter that should always be a 12-digit number, or that your search endpoint should never receive a POST body larger than 2KB. Custom rules let you enforce that contract at the edge.

Here is a custom rule pattern I use frequently, expressed in a provider-agnostic JSON/Terraform style. This rule blocks anomalous access to an admin preview endpoint while allowing your internal preview service:

resource "edge_waf_custom_rule" "block_admin_preview_abuse" {
  name     = "block-admin-preview-probing"
  priority = 100
  action   = "block"
  expression = <<-EOT
    http.request.uri.path contains "/api/preview" and
    not ip.src in $allowlisted_preview_ips and
    (
      http.request.method != "GET" or
      not http.request.headers["x-preview-token"][0] matches "^prev_[a-zA-Z0-9]{32}$"
    )
  EOT
  description = "Block unauthenticated access to preview API. Allow only corporate IPs with valid token."
}

Notice the structure: we match on path, then explicitly allowlist, then check method and token format. The order matters for performance. Put the cheapest, most selective match first (uri.path contains). Edge engines evaluate rules top-down and short-circuit.

Another high-value custom pattern is enforcing content-type and size on API routes. Attackers love to send application/json payloads with SQLi to endpoints that expect JSON, because generic WAFs may not parse JSON correctly. A custom rule can be brutally effective:

# VCL-style edge logic for API payload validation
if (req.url.path ~ "^/api/v2/orders" && req.method == "POST") {
  if (req.http.Content-Type !~ "application/json") {
    call waf_block(403, "invalid_content_type");
  }
  if (std.integer(req.http.Content-Length, 0) > 8192) {
    call waf_block(413, "payload_too_large");
  }
  # Inspect JSON body for unexpected keys - lightweight custom check
  if (req.postBody ~ "\"(admin|role|isAdmin)\"\s*:") {
    call waf_log_and_block("privilege_escalation_attempt");
  }
}

That last check is not a full JSON parse — it is a fast regex pre-filter. If it fires, you can route the request to a more expensive inspection worker or simply block. In my experience, these simple business-logic rules catch more targeted attacks than adding another 50 CRS regexes.

Chaining WAF Signals With Bot and Rate Limiting Data

A WAF rule in isolation is binary. A WAF rule chained with bot score, JA3 fingerprint, or rate counter is contextual. Modern edge platforms expose these signals as variables you can use in WAF expressions. I strongly recommend chaining.

For example, instead of blocking all requests with a high CRS anomaly score, you can apply a stricter threshold for traffic that already looks automated. This hybrid approach links your WAF and your bot management layer. See Bot Management at the CDN: Fingerprinting, Challenges and Rate Limiting for a deeper implementation of fingerprinting at the edge.

A practical chained rule looks like this:

{
  "name": "strict-sqli-for-automated-clients",
  "condition": "crs_anomaly_score >= 5 AND (bot.score > 70 OR ja3.hash in $known_automation_ja3)",
  "action": "managed_challenge",
  "phase": "request"
}

This says: if you are only slightly suspicious (score 5) but you also look like a bot, challenge. If you are human-like, we require a higher score (10) to block. This dramatically reduces false positives for real users while maintaining pressure on automation. I have found that this single pattern reduced our false positive tickets by 60% while keeping block rates for attack traffic constant.

Performance, Ordering, and Rule Exclusions: Making the WAF Fast Enough for the Edge

Every microsecond you add at the edge is added to your Time to First Byte. A poorly ordered WAF with 300 regexes can add 40-80ms of latency. A well-ordered WAF with the same rules adds 2-5ms. The difference is entirely in how you structure execution.

Rule Execution Order Matters More Than Rule Count

Edge WAFs evaluate rules sequentially. You want your highest-signal, lowest-cost rules first, and your expensive, low-frequency rules last. My standard ordering for edge properties:

1. Allowlist / Bypass rules first. Health checks, monitoring probes, and your own office IPs. If ip.src in $monitoring_ips, skip all subsequent WAF inspection. This saves evaluation time for your most frequent legitimate traffic.

2. Rate limiting and geo-blocking. These are integer comparisons — extremely fast. Drop obvious volumetric abuse before running regex.

3. Custom business-logic rules. Cheap string matches on path/method/header that encode your application contract.

4. CRS PL1 critical rules (score 5). The most damaging attack signatures.

5. CRS PL1/PL2 remaining rules. Lower severity anomalies.

Most providers let you set priority or phase ordering. Use it. And always measure. I export WAF evaluation time via Server-Timing headers in staging to see per-rule latency.

Building Sustainable Exclusion Workflows

False positives are inevitable. The question is how you exclude them. I have seen two anti-patterns: disabling a rule globally because it broke one endpoint, and creating overly broad exclusions like "ignore all SQLi rules for this entire domain." Both leave you exposed.

A sustainable exclusion is narrow and justified. It targets a specific rule ID, on a specific parameter, on a specific path, and includes an expiration or review ticket.

For example, if your CMS uses a parameter content that legitimately contains HTML, rule 941320 (XSS) will fire constantly on POST /api/content/save. A good exclusion is:

Exclusion: Rule 941320 -> Parameter "content" -> Path "^/api/content/save$" -> Method POST -> Reason: Rich text editor, sanitized at origin -> Ticket: SEC-1421

A bad exclusion is:

Exclusion: Rule 941320 -> Domain "*" -> Reason: Too noisy

I recommend storing exclusions as code, reviewed in pull requests, just like application code. Many teams manage edge WAF via Terraform or provider APIs — use version control. And audit exclusions quarterly. I have found that 30% of exclusions created during launch are no longer needed after an application fix, but no one removes them.

Also consider using Security Headers via CDN: CSP, HSTS and Permissions-Policy at the Edge as a complementary layer. While WAF blocks inbound attacks, security headers mitigate the impact if an XSS payload does bypass the WAF. They are cheap, cacheable, and enforceable at the edge with zero inspection cost.

Observability at the Edge: Logging, Sampling, and Tuning Loops for WAF Rules

A WAF without observability is just a blocklist you hope is working. At the edge, observability is harder because you are dealing with tens of millions of events per hour. You cannot log every matched rule for every request without massive cost and noise.

In my experience, the most effective edge WAF observability stack has three tiers:

1. Sampled Full Request Logs: Log 1-5% of all requests that trigger any WAF rule, including full headers, normalized URI, rule IDs, anomaly score, and action taken (log/block/challenge). This is for forensic tuning. Sample rate should increase for high-severity blocks.

2. Aggregated Metrics and Histograms: For every rule ID, emit a counter: waf_rule_matched{rule="941100", action="block"}. Graph these in your monitoring system. A sudden spike in rule 932160 (RCE) is an early warning of a zero-day scan, even if your block rate stays flat. I alert on 3-sigma deviations for top 20 rules.

3. Anomaly Score Distribution: Histogram of anomaly scores for blocked vs. logged requests. If your median blocked score is 12 and your median logged score is 3, your threshold of 10 is working. If they converge, you have tuning work to do.

When tuning, I follow a weekly loop: Monday, review top 10 triggered rules by count. For each, check false positive rate via sampled logs and customer support tickets. If a rule is >5% false positive, create a narrow exclusion or raise its score contribution. Wednesday, review bypasses — search origin logs for attacks that reached origin but were not blocked at the edge. Did the edge fail to inspect the body? Was the rule disabled? Friday, review performance — p95 edge WAF evaluation time should stay under 3ms. If it creeps up, reorder or disable expensive regex.

One detail many teams miss: log the transformation that triggered the rule. The IETF Datatracker specifications for HTTP message parsing highlight how normalization can change payload visibility. If your log shows args:/search?q=%253Cscript%253E triggered rule 941110 after double URL decode, you know your transformation pipeline is working. If you only log the raw request, you cannot reproduce why a rule fired or missed.

Finally, test your WAF continuously. I run a nightly canary that sends 50 crafted payloads (SQLi, XSS, path traversal, RCE) to a canary endpoint through the CDN and verifies they are blocked. If a provider updates their managed rule set or you deploy an exclusion that is too broad, the canary fails within hours, not after an incident. This is the same principle as chaos engineering, applied to security controls.

Frequently Asked Questions

Should I use the CDN's managed OWASP rule set or build my own custom rules?

Use both, but in layers. Start with the provider's managed OWASP CRS rule set at Paranoia Level 1 in anomaly scoring mode as your global baseline. It covers 90% of generic attacks with minimal tuning. Then add custom rules for your application-specific logic that CRS cannot know — like enforcing parameter formats, protecting admin paths, and chaining WAF scores with bot signals. I have never seen a property adequately protected by managed rules alone, and I have never seen a team successfully maintain 200 custom regex rules without missing coverage. The combination is stronger than either alone.

How do I safely test WAF rule changes without blocking legitimate users?

Always use a phased rollout with simulate/log-only mode first. Most edge platforms let you set a rule action to "log" or "simulate" which records a match but does not block. Deploy new rules or paranoia level increases in log-only for 48-72 hours, analyze the sampled logs for false positives on real traffic, create narrow exclusions, and then switch to block. For custom rules, scope them to a single staging hostname or a path like /api/test-waf first. I also recommend using a managed challenge action instead of hard block for medium-confidence rules — it filters bots without outright denying users who triggered a weak signal.

Why is my edge WAF missing attacks that ModSecurity blocks at origin?

This usually comes down to three edge limitations: body inspection limits, transformation differences, and response inspection gaps. Check your provider's body inspection limit — many only inspect the first 8KB-32KB by default, so large JSON payloads may be truncated before inspection. Verify transformation parity — test payloads with single and double URL encoding to see if the edge normalizes the same way as ModSecurity. And remember, edge WAFs rarely inspect origin responses, so data leakage or error disclosure rules will not fire at the edge. Keep a lightweight origin WAF or security logging layer for those cases, even when the edge handles inbound blocking.

How many custom WAF rules can I run at the edge before performance suffers?

It is less about count and more about cost and order. I have run properties with 150+ custom rules under 2ms evaluation time because 140 of them were cheap string matches on path or header that short-circuit early. Conversely, 10 poorly written regex rules with catastrophic backtracking can add 20ms and even cause CPU timeouts. As a rule of thumb, keep regex complexity low, anchor patterns to the start of fields where possible, avoid nested quantifiers like (.*.*), and always place allowlist and cheap matches first. Monitor p95 evaluation time and set an alert if it exceeds 3-5ms. If you need heavy inspection, offload it to a dedicated edge worker that only runs on a narrow set of paths.