The default Cloudflare WAF is good. The configured Cloudflare WAF is much better. Most companies stop at “enabled” — they turn on the Managed Ruleset, tick the OWASP Core Ruleset checkbox, and consider the WAF done.
That’s a defensible baseline. It leaves meaningful protection on the table. This guide covers what the default handles, five custom rule patterns worth configuring, how to think about Block / Challenge / Log actions, and the testing process that keeps changes from breaking production.
What the Cloudflare WAF Does by Default
Enabling Cloudflare’s WAF activates three protection layers automatically.
- Cloudflare Managed Ruleset — vendor-curated rules covering common web attacks (SQL injection, XSS, command injection). Cloudflare updates it as threats emerge.
- OWASP Core Ruleset — industry-standard open ruleset. More aggressive; can produce false positives. Cloudflare exposes a sensitivity dial to trade coverage against noise.
- Exposed Credentials Check — blocks logins where credentials appear in breach corpora, protecting against credential stuffing at the WAF layer.
Together these cover a meaningful portion of automated attack traffic. What they don’t cover is anything specific to the individual business. That’s what custom rules are for. For fundamentals, see our existing Cloudflare WAF explainer.
The 5 Custom Rule Patterns Every Business Should Configure
1. Block by geography
If a business doesn’t serve customers in a specific country and doesn’t have staff there, blocking traffic from that country at the edge is essentially free security value. Configure a Firewall Rule blocking requests matching a defined country list, with exceptions for legitimate origins (payment processors, monitoring). Run in Log mode for a week before switching to Block.
2. Rate limit login and password reset endpoints
The login page is the highest-value target on most sites. Credential stuffing sends thousands of username-password pairs per hour. Configure a Rate Limiting Rule on /login, /wp-login.php, /password-reset, and equivalents. Typical threshold: 5 requests per 60 seconds per source IP. Above that, JavaScript Challenge first, then Block. Same for password reset — otherwise attackers use it for user enumeration.
3. Bot management for high-risk paths
Checkout, cart, admin panels, and contact forms attract disproportionate automated traffic. Configure a Managed Challenge or Bot Management rule scoped to these paths — real users pass invisibly, automation trips. For ecommerce context, see Cloudflare CDN use cases.
4. Block known malicious User Agents
Certain user agent strings never represent legitimate traffic — old scanning tools, unmaintained scrapers, CMS vulnerability probes. Configure a Firewall Rule matching abusive User-Agent patterns via regex (nikto, sqlmap, masscan, wpscan, outdated python-requests versions). Catches meaningful automated abuse without touching real users. Update quarterly.
5. Admin path IP allowlist
Admin URLs — /wp-admin, /administrator, custom back-office paths — should be restricted to known IPs. This is the single highest-return custom rule for most businesses. Configure a Firewall Rule Blocking admin path requests where source IP is not in the allowlist. Include office static IPs, VPN egress ranges, admin work-from-home addresses. For teams using Cloudflare Mesh, the Mesh network can be the allowlist source directly.
Understanding WAF Actions: Block, Challenge, Log
- Block — request never reaches origin. Use for confirmed-malicious patterns.
- Managed Challenge — invisible verification. Real browsers pass; automation trips. Use for suspicious-but-unconfirmed traffic. Default for “not sure” rules.
- Log — no action, just records the match. Use for every new rule during its first week.
Common misconfigurations: blocking search-engine crawlers (Googlebot, Bingbot), blocking legitimate monitoring services (Uptime Robot, Pingdom), and blocking your own team members working from home. Each is worth checking before switching rules from Log to Block.
How to Test WAF Changes Without Breaking Production
The failure mode is blocking legitimate traffic and finding out from a customer complaint. Prevention: disciplined rollout.
- Deploy in Log mode first. Leave for at least a week. Review matches — if they include your own IPs, known-good crawlers, or legitimate customer traffic, refine the rule expression before switching action.
- Managed Challenge before Block. For uncertain rules (bot management, geography), an intermediate step lets real users pass while blocking automation.
- Rollback under 60 seconds. Document the rule ID and disable steps. When a complaint arrives, the team should disable the rule fast.
Frequently Asked Questions
Do I need custom rules if I use the OWASP Core Ruleset?
Yes. OWASP covers generic web attack patterns. It doesn’t know your login endpoint is at /account/signin or that you don’t serve customers in specific countries. Custom rules encode business-specific knowledge no managed ruleset can.
Will WAF rules slow down my site?
Not noticeably. Rules evaluate at the edge in milliseconds. Blocking bad traffic at the edge actually reduces origin load and speeds legitimate responses.
Should I use Cloudflare’s Bot Management add-on?
For most Pro/Business tenants, built-in Bot Fight Mode plus custom Managed Challenges on high-risk paths is sufficient. The paid add-on becomes worthwhile for high-volume ecommerce, financial services, or media where sophisticated bots (rotated IPs, headless browsers) are a documented problem.
Get Your Cloudflare WAF Configured for Real Traffic
Configuring the Cloudflare WAF correctly is one of the highest-return security actions a company can take. The default protections are good; the configured protections are transformative. ANP Technology designs, deploys, and tunes Cloudflare WAF configurations — from initial custom rule sets through to Bot Management strategy and ongoing rule refinement.
Talk to ANP Technology about your Cloudflare configuration →
