WAF & Edge Security

Sanitized WAF and edge security content built from real Cloudflare-fronted web deployments.

This repository focuses on custom Cloudflare WAF rules, rate limiting expressions, origin lockdown configurations, edge cache and security tradeoffs, and operator-safe implementation guidance. It is meant to be useful to defenders running Cloudflare-protected websites, and readable to engineers or business owners reviewing the work.

Scope

This repository includes:

• Custom Cloudflare WAF rule expressions in the current Rules Engine syntax
• Rate limiting rule expressions for common abuse targets
• Origin server lockdown configurations for Apache, Nginx, and UFW
• Cache and security policy tradeoff references
• Bot mitigation rule expressions using the Cloudflare bot score field
• Documentation written around manual placement, validation, rollback, and tuning discipline

This repository does not include:

• Terraform modules or full deployment automation
• Cloudflare API automation scripts that modify production zones
• Enterprise-only features that require account-level deployment
• Pre-built rulesets for niche edge cases without rationale
• Claims that every rule here is universally safe to deploy without tuning

Why this repository exists

A lot of public Cloudflare WAF content is either outdated (still using the legacy Firewall Rules dashboard), too narrow (single-rule blog posts), or too aggressive (rules that block legitimate traffic). The goal here is different:

• keep the structure clean
• keep the scope honest
• use only the current Rules Engine expression syntax
• document real operational tradeoffs
• make validation and rollback first-class parts of the workflow

Who this is for

This repository is aimed at:

• Cloudflare WAF practitioners running the dashboard or API
• Web developers and agencies managing Cloudflare zones
• Site owners on Cloudflare Free, Pro, or Business plans
• Security engineers handling edge-layer protection
• Blue team engineers reviewing edge configurations
• Business owners reviewing the work of Web Stack Defense

Baseline environment

The content in this repository was shaped against real Cloudflare-fronted web deployments running:

• Cloudflare Free, Pro, and Business plan zones
• Cloudflare Rules Engine (the current custom rules system, not the deprecated Firewall Rules)
• Cloudflare Bot Fight Mode (Free) and Super Bot Fight Mode (Pro/Business) — score field exposed
• Cloudflare Enterprise Bot Management — full bot_management fields including verified_bot
• Origin servers running Apache 2.4 or Nginx 1.24 on Ubuntu 22.04 LTS and Ubuntu 24.04 LTS
• WordPress 6.x as the primary application layer in most test environments

For exact version and environment notes, see TESTED_ON.md.

Repository layout

configs/
  cloudflare/
  origin/

checklists/

scripts/

examples/

Content design

The repository is intentionally split into:

Cloudflare rule expressions Custom rules and rate limit rules written in the Cloudflare Rules Engine expression syntax. Each rule is paired with an action (block, managed_challenge, js_challenge, log) and inline documentation explaining what it matches, why, and what to watch for. Rules are written as expressions ready to paste into the Cloudflare dashboard, not as full API payloads.

Origin lockdown configurations Server-side configurations that restrict origin server access to Cloudflare IP ranges only. This is the critical companion to any Cloudflare deployment — a WAF that can be bypassed by hitting the origin directly is not actually protecting anything.

Checklists Operational checklists for initial WAF deployment, rule tuning, and false positive workflows. Written to be used during real reviews, not just read once.

Scripts Lightweight scripts for refreshing the Cloudflare IP allowlist on origin servers. No script in this repository modifies a Cloudflare zone via API — all dashboard changes are documented as manual steps.

Installation philosophy

This repository assumes manual rule creation and deployment.

That is deliberate.

WAF rules can block legitimate traffic, break checkout flows, lock out admin users, and create support volume. The realistic value of a public WAF rule pack is as a reference to adapt, not a copy-paste deployment. Every rule below should be evaluated against the specific traffic pattern, application behavior, and user base of the site it protects.

Review the rule. Understand what it matches. Deploy it in log action first. Review the matches over 24 to 72 hours. Tune the expression if needed. Promote to managed_challenge or block only after the log data is clean.

Validation workflow

Recommended order for any new rule:

1. Read the expression and confirm you understand exactly what it matches
2. Confirm the rule does not duplicate or conflict with an existing rule
3. Deploy the rule in log action only
4. Wait 24 to 72 hours and review the matches in Cloudflare's Security Events log
5. Check for false positives by reviewing matched requests for legitimate traffic
6. Tune the expression if false positives are found, or accept the rule as-is
7. Promote to managed_challenge or block after log data is clean
8. Document the rule, its purpose, and any tuning applied

Skipping the log phase is how working sites break.

Risks and guardrails

This repository assumes you understand the following risks:

• WAF rules can block legitimate users if the expression is too broad
• Rate limit rules can lock out shared-IP traffic (corporate networks, schools, mobile carriers)
• Origin lockdown rules can block legitimate monitoring, backup, and maintenance traffic if not scoped carefully
• Cloudflare IP ranges change over time and allowlists must be refreshed
• Bot management rules using cf.bot_management.score require Super Bot Fight Mode (Pro/Business) or Enterprise Bot Management; cf.bot_management.verified_bot requires Enterprise Bot Management
• The Rules Engine has a per-rule expression length limit of 4,096 characters
• Free plan zones have a limit on custom rules; Pro and Business plans allow more (verify current limits in your Cloudflare dashboard)
• Cache rules and security rules can interact in non-obvious ways

Redaction policy

Nothing in this repository should expose:

• public or internal IP addresses tied to a real deployment
• domains tied to private infrastructure
• Cloudflare zone IDs, account IDs, or API tokens
• usernames or customer identifiers
• hostnames unique to a specific deployment
• file paths that would only exist in a single environment

All examples use the documentation reserved range 203.0.113.0/24 for IP addresses, example.com for domain names, and clearly marked placeholder variables for credentials and account identifiers. Cloudflare's own IP ranges are reproduced where required for origin lockdown — those are public information sourced from the official Cloudflare API at https://api.cloudflare.com/client/v4/ips.

Affiliate disclosure

Some setup notes may reference Cloudflare or other commercial security tools using affiliate links. If you choose to use one, Web Stack Defense may receive a referral credit at no extra cost to you. Support is appreciated, but use whatever provider or tool fits your environment.

Related platform

This repository is part of the broader website security work documented at Web Stack Defense. Guides on the site go deeper into context, tradeoffs, and implementation decisions. The rule expressions and configurations here are the practical artifacts that sit alongside those guides.

Contribution policy

Issues and curated pull requests are allowed, but this is not an open-ended community repo where every submission will be merged.

Security issues should be reported privately according to SECURITY.md.

Contribution standards are documented in CONTRIBUTING.md.