Cloudflare WAF Rules That Actually Stop Real Attacks (Without Breaking Legit Users)

Most WAF failures are self-inflicted. Teams either deploy almost nothing and trust defaults, or they overreact and block normal users, checkout flows, and APIs.

Good Cloudflare WAF operations are not about extreme blocking. They are about targeted friction for bad traffic while preserving legitimate conversions.

This is the operating model I use for WordPress and WooCommerce environments handling real customer traffic.

Why "Block Everything" Fails

Security teams under attack pressure often create broad rules with weak conditions:

• Block entire countries without business analysis.
• Block all bots without exception handling.
• Block suspicious patterns globally with no path context.
• Add overlapping custom rules that conflict with managed protections.

Result: false positives, broken checkout, locked-out editors, support burden, and emergency rollback.

A WAF should enforce intent, not panic.

Baseline Configuration Before Custom Rules

Custom rules are not the first step. First, verify baseline settings.

SSL/TLS mode

Use Full (strict) whenever possible. Flexible mode creates avoidable risk and origin confusion.

Caching posture

• Cache static assets aggressively.
• Keep dynamic app routes controlled.
• Do not cache authenticated pages or cart/checkout endpoints without explicit strategy.

Security level

Set a reasonable default first. For many production sites, this means moderate sensitivity and path-specific hardening later.

Bot controls

• Use bot protection where you actually receive bot abuse.
• For high-traffic forms and login pages, combine bot controls with rate limiting.
• Avoid turning every aggressive option to maximum on day one.

Baseline objective: stable, observable behavior before you add strict custom logic.

Managed Rules vs Custom Rules

Treat managed rules and custom rules as complementary.

Managed Rules: start here

Managed rules provide maintained signatures for common exploit classes. Enable relevant sets and review actions.

Checklist:

• Enable managed rulesets appropriate for your stack.
• Start with default actions, then tighten only where evidence supports it.
• Track top triggering rule IDs weekly.

Custom Rules: use for your app behavior

Custom rules are for your specific abuse patterns:

• Login brute force patterns.
• XML-RPC abuse patterns.
• Enumeration probes.
• Path-specific anomalies.

Custom rules should be small, explicit, and path-aware.

Rate Limiting Patterns That Work for WordPress

Rate limiting is where many attacks are neutralized with minimal user impact.

wp-login.php

Goal: reduce credential stuffing and brute force.

Pattern:

• Match POST to /wp-login.php.
• Count per IP over short windows.
• Action: challenge first, then block on repeated burst behavior.

Practical guidance:

• Use challenge before hard block for unknown clients.
• Maintain separate thresholds for authenticated office IPs vs public traffic.

xmlrpc.php

If not needed, block it outright.

If needed (some integrations still use it):

• Allow only known clients.
• Apply strict low-rate thresholds.
• Challenge suspicious bursts.

/wp-json

API traffic is often legitimate but can be abused for enumeration and scraping.

Pattern:

• Apply method-aware limits.
• Allow known integrations by token or source identity where possible.
• Protect high-cost endpoints more aggressively than read-only low-cost endpoints.

Search endpoints and high-cost queries

Search and filter endpoints are common abuse surfaces for resource exhaustion.

Pattern:

• Rate limit repetitive query bursts.
• Challenge when anomaly score is high.
• Block only after repeated abuse indicators.

Allowlist Strategy Without Shooting Yourself in the Foot

Allowlisting is necessary, but over-allowlisting removes protection exactly where you need it.

What to allowlist

• Known office egress IPs for admin workflows.
• Monitoring/uptime providers.
• Payment provider callback endpoints (with strict validation).

What not to allowlist

• Entire ASN ranges unless fully justified.
• Any traffic that is "probably internal" without verification.
• Broad path wildcards for convenience.

Guardrails

• Scope allowlists by path and method whenever possible.
• Add expiration and owner notes for every allowlist entry.
• Review allowlists monthly.

Challenge vs Block: Practical Decision Rules

The right action depends on confidence and business impact.

Use challenge when

• Confidence is moderate.
• User value is high (checkout, account login, contact forms).
• You are still tuning thresholds.

Use block when

• Confidence is high and repeated.
• Path is non-user-facing and clearly abusive.
• Known malicious fingerprints reoccur.

A common progression:

1. Log only (short period).
2. Managed challenge.
3. Hard block after confidence is proven.

This reduces collateral damage while keeping response time fast.

Logging and Visibility: Your Tuning Engine

You cannot tune what you do not observe.

Minimum visibility loop

• Review Firewall Events daily during active attacks.
• Track top attacked paths, countries, ASNs, user agents, and actions.
• Compare blocked/challenged traffic against app logs and conversion metrics.

WAF analytics questions to ask weekly

• Which rules generated most actions?
• Which rules triggered false positives?
• Which endpoints consumed most mitigation effort?
• Did we reduce origin load and auth abuse this week?

Store enough history

Keep historical views long enough to detect patterns (campaign recurrence, attacker adaptation, seasonal traffic changes).

Iteration Cycle (How Rules Stay Effective)

Treat WAF policy as an operational loop, not one-time setup.

Weekly cycle

1. Review event data.
2. Identify one high-value false positive to fix.
3. Identify one high-frequency attack pattern to tighten.
4. Deploy small changes.
5. Re-evaluate impact after 24-72 hours.

Small, measurable changes beat large rewrites.

Common Gotchas

False positives on APIs

Custom rules written for browser traffic can break API clients. Use route-specific conditions and method checks.

WooCommerce checkout breakage

Checkout paths are sensitive to cookie behavior, payment redirects, and script calls. Never push strict blocks there without staged validation.

Admin lockouts

Aggressive rules on login/admin paths can lock your own team during incident response. Keep a tested emergency access path with strict controls.

Rule shadowing

Multiple overlapping rules can make debugging hard. Keep rule names clear and avoid redundant conditions.

Ignoring origin logs

Cloudflare events tell only part of the story. Correlate with origin logs to confirm attack effect and application impact.

Example Rule Logic (Text, Not Giant Dumps)

A practical pattern for login abuse:

• Condition A: request path is /wp-login.php and method is POST.
• Condition B: request count from same source exceeds threshold in short window.
• Condition C: source is not in approved office/monitor allowlist.
• Action 1: managed challenge for first threshold breach.
• Action 2: block for repeated threshold breaches within larger window.

This approach preserves legitimate logins while draining automated attack effectiveness.

Another practical pattern for XML-RPC:

• If XML-RPC is unused, block all requests.
• If used, allow known integration identities and challenge all other high-rate traffic.

Simple logic, explicit intent, measurable outcome.

A Production-Ready Starter Checklist

Use this to stand up or reset WAF posture safely.

• Confirm SSL/TLS mode is Full (strict).
• Enable managed rulesets for your stack.
• Add rate limiting for login and XML-RPC surfaces.
• Add targeted limits for costly API/search endpoints.
• Add minimal allowlists with owner and expiry.
• Start risky custom rules in challenge mode.
• Correlate Cloudflare events with origin logs.
• Tune one false positive and one abuse pattern every week.

Final Notes

A useful WAF policy is boring in the best way: legitimate users pass, abusive automation slows down, and origin load stays stable during attack periods.

Do not optimize for how aggressive your rules look in screenshots. Optimize for real outcomes: fewer compromised accounts, fewer support escalations, and stable conversion paths.

If you want me to review your Cloudflare WAF posture and tune rules against your actual traffic, use the contact page.