How to Create Rate Limiting Rules in Cloudflare WAF: A Practical Guide to Preventing Brute Force, Blocking Malicious DDoS, and Protecting API Endpoints

In the contemporary online environment, whether it is a personal blog, a corporate official website, or a SaaS cloud platform, almost every day they endure threats from automated botnets and crawler programs around the world. Hackers often use scripts to repeatedly try account passwords for “brute force” attacks, frequently call high-load query interfaces to consume host resources, or send large numbers of malicious requests to API endpoints to launch “layer-7 application-layer DDoS attacks”.

As the world’s leading cloud security and content delivery network (CDN) giant, Cloudflare provides a powerful and flexible “Rate Limiting Rules” feature within its “Web Application Firewall (WAF)”. Through precise request frequency control, site administrators can identify and intercept abnormal bursts of traffic within milliseconds, ensuring the stable operation of the backend origin server.

This article will walk you step by step through the process of setting up rate limiting rules, key parameter configuration techniques, and classic defense scenarios.

Step-by-Step Operation for Creating Cloudflare WAF Rate Limiting Rules

Simply log in to the Cloudflare management console, and you can complete the deployment through an intuitive visual interface or compound expressions:

1. Log in to the Cloudflare Dashboard
   Go to the Cloudflare Dashboard and log in to your account.
2. Select the target domain
   In the site list, click the target website domain (Zone) you are preparing to configure security defense for.
3. Navigate to the WAF security settings page
   In the left-hand navigation bar, click “Security” > “WAF” in order.
4. Enter the rate limiting rules tab
   In the top tabs of WAF, switch to “Rate limiting rules” and click the “Create rule” button on the right.

Detailed Explanation of Core Configuration Parameters and Practical Settings

On the rate limiting rule editing page, the system provides highly customizable condition filters and action definitions:

Three Common Practical Defense Scenarios

Scenario 1: Protecting the WordPress Login Entrance and Blocking Brute Force

WordPress’s default /wp-login.php and /xmlrpc.php are the targets most commonly used by hacker scripts to launch brute-force credential stuffing. By limiting the frequency of POST requests, dictionary attacks can be completely dismantled:

• Matching expression:
  (http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
• Threshold setting: More than 5 requests within 1 minute.
• Action: Block (returns HTTP 429 status code) or Managed Challenge.
• Mitigation time: Restrict for 5 minutes.

Scenario 2: Protecting Sensitive API Endpoints and SMS/Email Verification Code Interfaces

Many web services provide “send verification code” or “reset password” APIs, which are often used by malicious actors as SMS bombing tools, causing website owners to bear huge third-party SMS costs:

• Matching expression:
  (http.request.uri.path starts_with "/api/v1/auth/send-code" and http.request.method eq "POST")
• Threshold setting: More than 2 requests within 1 minute.
• Action: Block.
• Mitigation time: Restrict for 1 hour.

Scenario 3: Excluding Internal Administrators and Known Office IP Whitelists

If the internal team or crawlers (such as Googlebot) need to frequently access certain resources, be sure to add exception exclusions to the matching conditions to avoid harming your own business:

• Matching expression:
  (http.request.uri.path starts_with "/api/" and not ip.src in {203.0.113.1 198.51.100.5})

Best Practices and Notes on Avoiding False Positives

1. Make good use of “Log (record only)” mode in the early stage of launch
   When creating a new rate limiting rule, it is recommended to first set the action to “Log” and continuously observe the trigger records for 24 to 48 hours. After confirming that there is no harm to the operating rhythm of normal users, switch the action to the formal “Block” or “Managed Challenge”.
2. Beware of NAT shared IPs causing false positives against legitimate users
   University campuses, public transit WiFi, large corporate offices, or public mobile networks often use NAT architecture, where hundreds or thousands of users share the same public external IP. If the threshold is set too extreme (for example, blocking after more than 3 requests in 1 second), it is very easy to cause a large number of legitimate visitors to be unable to browse. In most scenarios, prioritizing “Managed Challenge” is friendlier and safer than directly blocking.
3. Pay attention to Cloudflare plan quota limits
   Cloudflare’s Free Tier usually provides a limited number of rate limiting rules and a basic billing quota; while the Pro, Business, and Enterprise plans support more detailed header matching, custom 429 error response pages, and higher concurrency handling capacity. When scaling up, you should regularly review usage reports.