WAF Custom Rules is a rule builder in the Cloudflare dashboard that lets you describe any traffic filtering condition without writing code. The rule runs at the edge of the Cloudflare network before a request reaches the server, so it does not add extra load on the origin.
Custom Rules are needed when the default Managed Rules are not enough: for example, you need to block requests to a specific path with a rare User-Agent, close admin access by country, or allow verified partners through an API-key header.
How to create a custom rule in the dashboard
The rule is created under Security → WAF → Custom rules. The steps are the same for any scenario.
- Open the Custom rules tab and click Create rule.
- Give the rule a clear name — it will appear in the logs.
- Build the condition with the visual editor or type the expression manually.
- Choose an action: Block, Challenge, JS Challenge, Managed Challenge, Log, or Skip.
- Save and deploy the rule after checking the match preview.
Fields, operators, and actions in the rule builder
A rule condition is built from a request field, a comparison operator, and a value. The table below shows the basic set that covers most tasks.
| Field | Typical operator | Action |
|---|---|---|
| URI Path | contains, equals | Block |
| IP Source Address | is in, is not in | Challenge |
| User Agent | contains | JS Challenge |
| Country | equals, is in | Managed Challenge |
Rule examples for common tasks
Below is an expression in Cloudflare Rules language that blocks requests to the admin page without the required authorization header.
(http.request.uri.path contains "/wp-admin") and not (http.request.headers["x-api-key"][0] eq "secret-value")- Blocking by path and missing header — admin access only for trusted clients.
- Country restriction for a registration form when the service operates in one region.
- Challenge for requests without a standard Accept-Language header, typical of bots.
Custom Rules versus other protection layers: how to choose
Custom Rules are manual if-then conditions, while Firewall rules in the legacy interface solve a similar task with simpler syntax. If the plan supports both, new projects should pick Custom Rules — the interface is developed more actively.
When the task is not to block but to limit the request rate from one address, the right tool is Rate Limiting, not a WAF rule with a manual counter.
How to test and debug a rule
After enabling a rule, send a test request and check the event under Security → Events. It shows exactly which rule fired and which action was applied.
curl -I -A "test-agent" https://example.com/wp-admin/If no event appears, check the rule order: an earlier rule with the Skip action can stop processing before the needed condition is reached. The overall traffic picture is easy to see in Cloudflare Analytics — it shows the share of blocked requests per rule.
Checklist before launching a rule
- The rule name is clear and reflects its purpose.
- The condition was checked against the match preview.
- The action matches the risk — no Block where Log is enough.
- Rule order puts narrower conditions higher in the list.
- After publishing, it was verified with a real request and the event log.