Cloudflare’s Web Application Firewall (WAF) can be a powerful shield against Layer 7 (application layer) attacks, but its default ruleset might not catch everything. Crafting custom rules gives you granular control to block specific threats tailored to your application.
Let’s see it in action. Imagine you’re seeing a surge of requests trying to exploit a known vulnerability in an older CMS plugin, something like wp-content/plugins/vulnerable-plugin/exploit.php. Your goal is to block any requests targeting this specific file path, regardless of the HTTP method.
Here’s how you’d set that up in Cloudflare:
- Log in to your Cloudflare dashboard.
- Navigate to Security > WAF > Custom rules.
- Click Create custom rule.
- Rule Name:
Block Vulnerable Plugin Exploit - Field:
URI path - Operator:
equals - Value:
/wp-content/plugins/vulnerable-plugin/exploit.php - Field:
Logical Operator(Add another condition) - Field:
Request method - Operator:
is any of - Value:
POST,GET,PUT,DELETE,OPTIONS,HEAD,PATCH,TRACE - Action:
Block - Click Deploy.
Now, any request to that exact path, using any common HTTP method, will be blocked by Cloudflare before it even reaches your origin server. This is effective because it stops malicious traffic at the edge, reducing load and preventing potential compromise.
The mental model here is about pattern matching at the edge. Cloudflare WAF rules operate on a set of criteria you define. When a request hits Cloudflare’s network, it’s evaluated against these rules. If all conditions in a rule match, the specified action (like blocking, challenging, or logging) is taken. You’re essentially telling Cloudflare, "If you see this specific signature in a request, treat it as malicious and stop it."
The power comes from the Fields you can inspect. Beyond URI path and Request method, you can examine:
User-Agent: To block requests from known malicious bots or specific user agents.IP Source Address: To block entire IP ranges or specific IPs.HTTP Method: As seen in the example, useful for targeting specific types of requests.URI Query String: To catch attacks embedded in URL parameters.Request Body: For more complex attacks that don’t show up in the URL or headers (requires Enterprise plan).Country: To block traffic from specific geographic regions.
You can combine these fields using logical operators (AND, OR) to create highly specific rules. For instance, you might block GET requests to /admin.php that also have a User-Agent containing "sqlmap" and originate from a specific country.
Understanding how Cloudflare evaluates these rules is key. It’s a sequential process. Rules are processed in the order they appear in your custom rules list. If a request matches a rule, the action is executed, and often, processing stops for that request unless you’ve configured specific behaviors like "Continue" or "Skip". This order of operations means you can have a broad "Allow" rule at the bottom and then more specific "Block" rules above it, ensuring the specific blocks take precedence.
The most surprising thing most people don’t realize is the sheer flexibility of the URI path operator. It’s not just equals. You can use starts with, ends with, contains, matches regex, and even does not contain. This means you can block entire categories of attacks. For example, to block any request that looks like it’s trying to access sensitive configuration files across your entire site, you could create a rule with URI path contains /../ and Action: Block. This single rule can stop a wide range of directory traversal attempts without you needing to know every single malicious filename.
Once you’ve mastered custom rules for blocking, the next logical step is to explore the Managed Rulesets. These are pre-configured rulesets maintained by Cloudflare and security vendors, designed to protect against common threats like SQL injection and cross-site scripting (XSS) without you needing to write individual rules for each.