Edge Standard
Cloudflare WAF Optimization: Strategy and Configuration Guide
To learn more about the security philosophy, refer to Enhanced Security and Simplified Controls with Automated Botnet Protection.
To configure Cloudflare WAF provides immediate protection. A critical second step is to implement custom security rules tailored to the specific requirements of the application. The following rule sets apply to various scenarios. You must evaluate these rules based on the unique infrastructure.
The machine learning algorithm of Cloudflare classifies each request with a score from 1 to 99. A score of 1 indicates a malicious request, and a score of 99 indicates clean traffic. You must define rules to challenge or block requests based on these thresholds. For example, block all requests with an attack score below 20 and challenge requests with scores between 20 and 50.
Block Malicious Attacks
Rule Expression: cf.waf.score le 20
Set the action to Block to drop high-confidence malicious requests at the edge.
Challenge Likely-Malicious Attacks
Rule Expression: cf.waf.score gt 20 and cf.waf.score le 50
Set the action to Managed Challenge to verify suspicious traffic without outright blocks on legitimate users.
Legitimate browsers typically send standard User-Agent strings such as Chrome, Firefox, and Safari. Non-standard or empty User-Agents indicate automated scripts. Unless you specifically permit helpful bots or internal security tools, you must challenge or block these requests. For example, block empty User-Agents or identify common scripting tools such as python-requests or curl to mitigate automated probes.
Block Suspicious User-Agents
Rule Expression: http.user_agent wildcard r"python-requests/" or http.user_agent wildcard r"Go-http-client/" or http.user_agent wildcard r"curl/" or http.user_agent wildcard r"Wget/" or http.user_agent wildcard r"Nmap*"
Set the action to Block or Managed Challenge to prevent automated probes.
This rule prevents unauthorized access to maintenance scripts, install routines, or configuration files. This rule effectively stops bots from discovery of vulnerabilities. For example, issue a Challenge or Managed Challenge for requests to paths such as /user/login, /core/install.php, /composer.json, .env, and .git.
Zero-Tolerance Path Protection
Rule Expression: http.request.uri.path contains ".git" or http.request.uri.path contains ".docker" or ends_with http.request.uri.path, ".env" or ends_with http.request.uri.path, "composer.json"
Set the action to Block to deny access to sensitive configuration files and directories.
To serve specific geographic markets, filter traffic at the edge to Challenge or Block requests that originate from regions outside the operational area. For example, challenge or block all traffic that originates from outside the United States.
Challenge Requests from Outside the US
Rule Expression: ip.src.country ne "US"
Set the action to Managed Challenge to present challenges to users who connect from non-target regions.
Request rate limits serve as a critical safety valve to prevent resource exhaustion and protect against brute-force attacks. For example, implement request limits on resource-intensive paths targeted by SEO crawlers or utility paths such as /search and /contact. Authentication endpoints such as /user/login, /user/password, and /user/register are primary candidates.
Rate Limit Sensitive Paths
Rule Expression: http.request.uri.path wildcard r"/user/*"
Track request rates per IP, for example, maximum 30 requests per 10 seconds, and block or challenge traffic that exceeds the threshold.
Direct blocks of specific IPs or Autonomous System Numbers, ASNs, are standard reactive measures based on traffic analysis.
For example, block ASNs associated with cloud data centers that do not generate legitimate traffic. Use this strategy carefully to avoid blocks on legitimate users routed through shared infrastructure.
Block Malicious ASN
Rule Expression: ip.src.asnum eq 45102
Set the action to Block with a 403 response code for designated untrusted ASNs.
Reduce WordPress Probe Noise
For Drupal-based applications, blocks on common WordPress-specific paths reduce log noise and prevent bots from scans for irrelevant vulnerabilities. For example, block requests to /wp-login.php, /wp-admin/, and /xmlrpc.php.
Block WordPress Scanner Paths
Rule Expression: starts_with http.request.uri.path, "/wp-" or http.request.uri.path eq "/xmlrpc.php"
Set the action to Block with a 403 response code.
These recommendations focus on Drupal and Acquia environments. Refer to Cloudflare documentation to find standard custom rule use cases. Because business requirements vary, adapt these rules to best fit the logic and security profile of the application.
These rules provide a solid starting point for the initial Edge Rules setup. To keep the application secure requires ongoing education and adjustments based on specific traffic patterns.
Web security evolves rapidly in the AI era. According to Cloudflare Radar, approximately 61% of current traffic consists of bots, [https://radar.cloudflare.com/traffic#bot-vs-human].
Modern automated threats use sophisticated spoof techniques such as rotating IPs, user agents, data centers, and ASNs to make bot traffic much harder to detect. Defense against these threats requires traditional network firewall rules and behavioral analysis.
To explore this topic, refer to the related articles:
To explore Advanced Bot Management, contact the Account Manager to discuss available options.
Edge Standard