{"id":3415,"date":"2025-12-26T17:04:24","date_gmt":"2025-12-26T14:04:24","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/cloudflare-security-settings-guide-waf-rate-limiting-and-bot-protection\/"},"modified":"2026-11-04T21:43:38","modified_gmt":"2026-11-04T18:43:38","slug":"cloudflare-small-business-security","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/cloudflare-small-business-security\/","title":{"rendered":"Cloudflare Security for Small Businesses: WAF and Bots"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Cloudflare can add WAF, rate limiting and bot protection to a small business website, but the available controls depend on the plan and selected product. This guide covers corporate sites, blogs, WooCommerce stores, SaaS pages and client portals hosted at DCHost. It explains how to identify sensitive paths, choose supported rule examples and verify that legitimate customers and integrations still work. Thresholds below are illustrative starting points, not measurements from customer deployments.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#How_Cloudflare_Fits_Into_Your_Website_Security_Stack\"><span class=\"toc_number toc_depth_1\">1.<\/span> How Cloudflare Fits Into Your Website Security Stack<\/a><\/li><li><a href=\"#Baseline_Security_Hygiene_In_Cloudflare_Before_WAF_Rules\"><span class=\"toc_number toc_depth_1\">2.<\/span> Baseline Security Hygiene In Cloudflare Before WAF Rules<\/a><ul><li><a href=\"#1_Secure_your_Cloudflare_account\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> 1. Secure your Cloudflare account<\/a><\/li><li><a href=\"#2_Choose_the_right_SSLTLS_mode\"><span class=\"toc_number toc_depth_2\">2.2.<\/span> 2. Choose the right SSL\/TLS mode<\/a><\/li><li><a href=\"#3_Protect_your_origin_IP\"><span class=\"toc_number toc_depth_2\">2.3.<\/span> 3. Protect your origin IP<\/a><\/li><\/ul><\/li><li><a href=\"#Configuring_Cloudflare_WAF_For_Small_Business_Websites\"><span class=\"toc_number toc_depth_1\">3.<\/span> Configuring Cloudflare WAF For Small Business Websites<\/a><ul><li><a href=\"#1_Enable_and_update_managed_rulesets\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> 1. Enable and update managed rulesets<\/a><\/li><li><a href=\"#2_Identify_your_critical_URLs_first\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> 2. Identify your critical URLs first<\/a><\/li><li><a href=\"#3_Create_targeted_WAF_rules_for_login_and_admin_areas\"><span class=\"toc_number toc_depth_2\">3.3.<\/span> 3. Create targeted WAF rules for login and admin areas<\/a><\/li><li><a href=\"#4_Use_WAF_for_basic_geo_and_ASN_filtering_carefully\"><span class=\"toc_number toc_depth_2\">3.4.<\/span> 4. Use WAF for basic geo and ASN filtering (carefully)<\/a><\/li><li><a href=\"#5_Log_test_and_tune_for_false_positives\"><span class=\"toc_number toc_depth_2\">3.5.<\/span> 5. Log, test and tune for false positives<\/a><\/li><\/ul><\/li><li><a href=\"#Rate_Limiting_Stopping_Abuse_Without_Hurting_Real_Users\"><span class=\"toc_number toc_depth_1\">4.<\/span> Rate Limiting: Stopping Abuse Without Hurting Real Users<\/a><ul><li><a href=\"#1_Basic_concepts_to_keep_in_mind\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> 1. Basic concepts to keep in mind<\/a><\/li><li><a href=\"#2_Rate_limiting_for_login_pages\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> 2. Rate limiting for login pages<\/a><\/li><li><a href=\"#3_Rate_limiting_for_APIs_and_search\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> 3. Rate limiting for APIs and search<\/a><\/li><li><a href=\"#4_Rate_limiting_for_checkout_and_payment_flows\"><span class=\"toc_number toc_depth_2\">4.4.<\/span> 4. Rate limiting for checkout and payment flows<\/a><\/li><li><a href=\"#5_Monitor_rate_limiting_analytics\"><span class=\"toc_number toc_depth_2\">4.5.<\/span> 5. Monitor rate limiting analytics<\/a><\/li><\/ul><\/li><li><a href=\"#Bot_Protection_Separating_Good_Bots_From_Bad_Traffic\"><span class=\"toc_number toc_depth_1\">5.<\/span> Bot Protection: Separating Good Bots From Bad Traffic<\/a><ul><li><a href=\"#1_Understand_Cloudflare_bot_scores_and_challenges\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> 1. Understand Cloudflare bot scores and challenges<\/a><\/li><li><a href=\"#2_Use_Bot_Fight_Super_Bot_Fight_Mode_carefully\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> 2. Use Bot Fight \/ Super Bot Fight Mode carefully<\/a><\/li><li><a href=\"#3_Harden_specific_endpoints_against_bots\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> 3. Harden specific endpoints against bots<\/a><\/li><li><a href=\"#4_Keep_a_clean_allowlist_of_good_bots_and_partners\"><span class=\"toc_number toc_depth_2\">5.4.<\/span> 4. Keep a clean allowlist of good bots and partners<\/a><\/li><\/ul><\/li><li><a href=\"#A_Practical_Cloudflare_Security_Blueprint_For_Small_Business_Sites\"><span class=\"toc_number toc_depth_1\">6.<\/span> A Practical Cloudflare Security Blueprint For Small Business Sites<\/a><ul><li><a href=\"#Step_1_Lock_down_basics\"><span class=\"toc_number toc_depth_2\">6.1.<\/span> Step 1: Lock down basics<\/a><\/li><li><a href=\"#Step_2_Turn_on_core_WAF_protection\"><span class=\"toc_number toc_depth_2\">6.2.<\/span> Step 2: Turn on core WAF protection<\/a><\/li><li><a href=\"#Step_3_Add_smart_rate_limiting\"><span class=\"toc_number toc_depth_2\">6.3.<\/span> Step 3: Add smart rate limiting<\/a><\/li><li><a href=\"#Step_4_Layer_bot_protection\"><span class=\"toc_number toc_depth_2\">6.4.<\/span> Step 4: Layer bot protection<\/a><\/li><li><a href=\"#Step_5_Combine_with_server-side_hardening\"><span class=\"toc_number toc_depth_2\">6.5.<\/span> Step 5: Combine with server-side hardening<\/a><\/li><li><a href=\"#Step_6_Monitor_iterate_document\"><span class=\"toc_number toc_depth_2\">6.6.<\/span> Step 6: Monitor, iterate, document<\/a><\/li><\/ul><\/li><li><a href=\"#Maintain_a_Measured_Security_Profile\"><span class=\"toc_number toc_depth_1\">7.<\/span> Maintain a Measured Security Profile<\/a><\/li><li><a href=\"#Primary_Sources\"><span class=\"toc_number toc_depth_1\">8.<\/span> Primary Sources<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_Cloudflare_Fits_Into_Your_Website_Security_Stack\">How Cloudflare Fits Into Your Website Security Stack<\/span><\/h2>\n<p>Before touching settings, it helps to be clear about what Cloudflare actually does in your architecture.<\/p>\n<p>For a web A, AAAA or CNAME record with the Cloudflare proxy enabled, HTTP\/HTTPS traffic reaches Cloudflare before your origin hosting account, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocation machine at DCHost. Changing nameservers alone does not proxy every service: DNS-only web records can expose the origin directly, and mail or verification records should not be proxied merely to enable security. Allowed requests reach the origin when Cloudflare cannot serve an eligible cached response.<\/p>\n<p>On traffic that actually passes through its proxy, Cloudflare can apply several complementary controls:<\/p>\n<ul>\n<li>Filtering and scoring HTTP traffic (WAF, bot detection, HTTP headers)<\/li>\n<li>Throttling abusive clients (Rate Limiting and other mitigation rules)<\/li>\n<li>Absorbing and filtering volumetric attacks (DDoS protection)<\/li>\n<\/ul>\n<p>But Cloudflare is not a replacement for server-side security. You still need secure Linux users, patched software, proper file permissions and backups on your hosting side. If you want a deeper server-side checklist, our article <a href='https:\/\/www.dchost.com\/blog\/en\/vps-security-checklist\/'>how to secure a VPS server without leaving doors open<\/a> is a good complement to this guide.<\/p>\n<p>Cloudflare can stop requests covered by effective edge rules before they reach the origin. That does not establish a guaranteed blocking rate or protect an origin path that bypasses the proxy.<\/p>\n<h2><span id=\"Baseline_Security_Hygiene_In_Cloudflare_Before_WAF_Rules\">Baseline Security Hygiene In Cloudflare Before WAF Rules<\/span><\/h2>\n<p>Secure account access and encrypted, authenticated origin connections complement WAF and rate limiting. Review these basics before adding more complex policies.<\/p>\n<h3><span id=\"1_Secure_your_Cloudflare_account\">1. Secure your Cloudflare account<\/span><\/h3>\n<ul>\n<li><strong>Enable two-factor authentication (2FA)<\/strong> for all users who can access your Cloudflare account. Verify the account email address before enrollment to avoid locking yourself out. If you signed up through a social login provider such as Google or Apple, first establish a Cloudflare password using the password reset process.<\/li>\n<li><strong>Use API tokens<\/strong> with least privilege instead of the global API key whenever tools or scripts need access.<\/li>\n<li><strong>Review account members<\/strong> regularly and remove ex-agency, ex-employee or unused access.<\/li>\n<\/ul>\n<h3><span id=\"2_Choose_the_right_SSLTLS_mode\">2. Choose the right SSL\/TLS mode<\/span><\/h3>\n<p>Use <strong>Full (strict)<\/strong> after verifying that the origin accepts HTTPS and presents an unexpired certificate matching the requested or target hostname, issued by a publicly trusted CA or Cloudflare Origin CA. For HTTPS visitor requests, Full encrypts the origin connection without the same certificate validation; an HTTP visitor request can still use plaintext HTTP to the origin. Flexible leaves the Cloudflare-to-origin leg unencrypted. Test renewal, redirects and HTTPS access before changing the mode.<\/p>\n<p>For server-side TLS, HSTS and certificate handling, see <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginx-apache-tls-hsts-ocsp-setup\/\">the TLS configuration guide for Nginx and Apache<\/a>. Certificate-related features depend on the issuing CA and certificate; do not assume every certificate supports OCSP stapling.<\/p>\n<h3><span id=\"3_Protect_your_origin_IP\">3. Protect your origin IP<\/span><\/h3>\n<p>If attackers can bypass Cloudflare and hit your origin IP directly, many of these settings become less effective.<\/p>\n<ul>\n<li>Where you control the origin firewall, restrict public web ports to Cloudflare\u2019s current IPv4\/IPv6 networks and any separately justified sources. First preserve management, health checks and certificate renewal paths. Coordinate this with the provider when using shared hosting.<\/li>\n<li>Review DNS-only records that expose the same origin; hiding an IP is not an access-control mechanism.<\/li>\n<li>Authenticated Origin Pulls requires the origin to validate the client certificate. Cloudflare\u2019s shared certificate proves Cloudflare-network origin, not your specific account. A suitable certificate unique to your configuration provides a narrower identity boundary. See <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-aop-mtls-origin-protection\/\">the Authenticated Origin Pulls and mTLS guide<\/a>.<\/li>\n<\/ul>\n<p>Once these basics are solid, you are ready to make the most of Cloudflare WAF, Rate Limiting and Bot Protection.<\/p>\n<h2><span id=\"Configuring_Cloudflare_WAF_For_Small_Business_Websites\">Configuring Cloudflare WAF For Small Business Websites<\/span><\/h2>\n<p>A WAF evaluates HTTP requests against its enabled rules. It can detect or block covered injection attempts, exploit patterns and scanners; it does not cover every vulnerability or replace patching your CMS and dependencies.<\/p>\n<p>If you are new to WAFs in general, you can first read our broader overview <a href='https:\/\/www.dchost.com\/blog\/en\/what-is-waf-cloudflare-modsecurity\/'>what is a Web Application Firewall and how Cloudflare WAF and ModSecurity work<\/a>, then come back here for Cloudflare-specific tuning.<\/p>\n<h3><span id=\"1_Enable_and_update_managed_rulesets\">1. Enable and update managed rulesets<\/span><\/h3>\n<p>In the current dashboard, inspect web application protections under <strong>Security \u2192 Settings<\/strong> and deployments under <strong>Security \u2192 Security rules<\/strong>. Older layouts place these under WAF. Check the plan distinction before selecting a ruleset:<\/p>\n<ul>\n<li><strong>Free:<\/strong> Cloudflare Free Managed Ruleset covers a selected set of high-impact, widely exploited vulnerabilities. It is not the full Cloudflare Managed Ruleset.<\/li>\n<li><strong>Pro and above:<\/strong> Cloudflare Managed Ruleset and Cloudflare OWASP Core Ruleset are available. Relevant WordPress or other application rules are selected through tags; do not assume every application has a separate ruleset product.<\/li>\n<li><strong>Deployment:<\/strong> Default actions vary by rule. Review the relevant tags and test login, cart, checkout and API flows before expanding scope. Do not enable every disabled rule or set the whole ruleset to Block simply as a starting default.<\/li>\n<\/ul>\n<p>Managed rules can add protection for covered vulnerabilities while you patch the application. They do not make outdated plugins safe, and a quiet event view does not prove that all attack paths are blocked.<\/p>\n<h3><span id=\"2_Identify_your_critical_URLs_first\">2. Identify your critical URLs first<\/span><\/h3>\n<p>Before creating custom WAF rules, make a short list of your sensitive paths. Common examples:<\/p>\n<ul>\n<li>Login pages: <code>\/wp-login.php<\/code>, <code>\/wp-admin\/<\/code>, <code>\/user\/login<\/code>, custom admin URLs<\/li>\n<li>XML-RPC or API endpoints: <code>\/xmlrpc.php<\/code>, <code>\/api\/<\/code>, <code>\/graphql<\/code><\/li>\n<li>E-commerce paths: <code>\/cart<\/code>, <code>\/checkout<\/code>, <code>\/my-account<\/code><\/li>\n<li>Search endpoints: <code>\/?s=<\/code>, <code>\/search<\/code>, <code>\/product-search<\/code><\/li>\n<\/ul>\n<p>Map these paths to actual application behavior before writing rules. A public AJAX handler and an administrator-only screen can share a directory; the presence of a cookie does not prove that the WAF has authenticated an application session.<\/p>\n<h3><span id=\"3_Create_targeted_WAF_rules_for_login_and_admin_areas\">3. Create targeted WAF rules for login and admin areas<\/span><\/h3>\n<p>Use explicit path matches and actions for sensitive endpoints. Start with a browser login path, then separately review admin screens, public handlers and API integrations.<\/p>\n<p>Example rule idea for WordPress logins:<\/p>\n<ul>\n<li><strong>Expression:<\/strong> <code>http.request.uri.path eq \"\/wp-login.php\"<\/code><\/li>\n<li><strong>Optional scope:<\/strong> Add source or country conditions only after checking legitimate administrators, corporate proxies, travel and integrations.<\/li>\n<li><strong>Action:<\/strong> Managed Challenge may suit an interactive browser login. It actively interrupts the request; it is not a logging or simulation mode.<\/li>\n<li><strong>Admin directory:<\/strong> Review <code>admin-ajax.php<\/code>, <code>admin-post.php<\/code> and other public handlers before challenging all of <code>\/wp-admin\/<\/code>.<\/li>\n<\/ul>\n<p>Cloudflare chooses the challenge according to the request. A legitimate browser may still fail or need interaction. HTML challenge pages do not directly suit clients expecting JSON, AJAX\/fetch responses, mobile APIs or payment webhooks; protect those flows using appropriate authentication and a response the client can handle.<\/p>\n<p>For non-WordPress sites, adjust paths accordingly to your login URL. Avoid using generic patterns that may accidentally include public pages.<\/p>\n<h3><span id=\"4_Use_WAF_for_basic_geo_and_ASN_filtering_carefully\">4. Use WAF for basic geo and ASN filtering (carefully)<\/span><\/h3>\n<p>For some small businesses that only serve a limited geography, it can make sense to challenge or block traffic from regions you never expect legitimate customers from. In Cloudflare WAF you can:<\/p>\n<ul>\n<li>Limit country-based conditions to paths covered by an explicit access policy; country is not proof of identity.<\/li>\n<li>Evaluate ASN and user-agent signals alongside observed traffic. A hosting network or unusual header alone does not establish malicious intent.<\/li>\n<li>Select the action separately. Current WAF custom rules do not have the general Allow action from legacy Firewall Rules.<\/li>\n<\/ul>\n<p>For example, the following custom expression selects WordPress admin paths requested from outside T\u00fcrkiye. With <strong>Block<\/strong> as the action, matching requests are denied. The two common public handlers are excluded here; adapt the exclusions to the actual application and change the country code to match your access policy:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">((http.request.uri.path eq &quot;\/wp-admin&quot; or starts_with(http.request.uri.path, &quot;\/wp-admin\/&quot;))\n and not http.request.uri.path in {&quot;\/wp-admin\/admin-ajax.php&quot; &quot;\/wp-admin\/admin-post.php&quot;}\n and ip.src.country ne &quot;TR&quot;)<\/code><\/pre>\n<p>This does not cover <code>\/wp-login.php<\/code> or authenticate the excluded handlers. Test legitimate administrators and integrations before enforcement. Whole-site geo-blocking can also disrupt travelling customers, search crawlers and cross-border partners.<\/p>\n<h3><span id=\"5_Log_test_and_tune_for_false_positives\">5. Log, test and tune for false positives<\/span><\/h3>\n<p>Whenever you add or change rules:<\/p>\n<ul>\n<li>WAF custom-rule Log is an Enterprise action. Check the separate availability for the rule type you are using; do not assume a universal Simulate mode.<\/li>\n<li>If a non-blocking action is unavailable, begin in staging or a tightly scoped test. A challenge is active enforcement.<\/li>\n<li>Inspect the rule ID and relevant events, then reproduce the legitimate flow.<\/li>\n<li>For a managed-rule false positive, skip only that rule under a narrow path\/method\/source condition. Place the exception before the relevant managed-ruleset deployment and use the correct account or zone scope. Avoid broadly skipping protections for an office IP.<\/li>\n<\/ul>\n<p>This review process helps detect false positives in payments, login and form submissions, so you can correct the specific rule and verify the affected flow again.<\/p>\n<h2><span id=\"Rate_Limiting_Stopping_Abuse_Without_Hurting_Real_Users\">Rate Limiting: Stopping Abuse Without Hurting Real Users<\/span><\/h2>\n<p>WAF conditions inspect request properties; rate limiting adds counters over time. It can reduce repeated abuse on selected endpoints, but a normal custom-rule expression does not count request frequency by itself.<\/p>\n<p>Create a Rate limiting rule under the current <strong>Security \u2192 Security rules<\/strong> interface. Rule count, matching fields, counting characteristics, periods and response options depend on your plan and contract.<\/p>\n<h3><span id=\"1_Basic_concepts_to_keep_in_mind\">1. Basic concepts to keep in mind<\/span><\/h3>\n<ul>\n<li><strong>Match:<\/strong> An explicit Rules language expression. The path field excludes the query string; appending <code>*<\/code> to an equality value does not make it a prefix match.<\/li>\n<li><strong>Threshold and period:<\/strong> The number of requests and the interval over which they are counted.<\/li>\n<li><strong>Characteristics:<\/strong> The example baseline uses IP. Users behind the same NAT\/proxy can share a counter, while different IPv4\/IPv6 addresses are distinct sources.<\/li>\n<li><strong>Action and duration:<\/strong> Block or a supported challenge action. The mitigation duration is separate from the counting period; serving cached content is not a rate limiting rule action.<\/li>\n<li><strong>Counting expression:<\/strong> Matching requests are counted by default. A custom counting expression does not automatically include the rule&#8217;s matching expression.<\/li>\n<\/ul>\n<p>Cloudflare does not maintain one global rate counter across its entire network: counters are scoped to data centers or associated geographical groups. Updates can be delayed, so excess requests may reach the origin. Enforce exact account, billing or payment quotas in the application as well.<\/p>\n<h3><span id=\"2_Rate_limiting_for_login_pages\">2. Rate limiting for login pages<\/span><\/h3>\n<p>The following examples use values shared by the current parameter and availability references. They are separate starting examples, not measured recommendations. Free has one rate limiting rule with a 10-second counting period and 10-second mitigation period; Pro has two rules and Business has five. All three examples cannot be deployed together on Free.<\/p>\n<table>\n<thead>\n<tr>\n<th>Endpoint and example minimum plan<\/th>\n<th>Expression<\/th>\n<th>Threshold per IP<\/th>\n<th>Action<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Login \u2014 Free<\/td>\n<td><code>http.request.uri.path eq \"\/wp-login.php\"<\/code><\/td>\n<td>10 requests in 10 seconds<\/td>\n<td>Block for 10 seconds<\/td>\n<\/tr>\n<tr>\n<td>Search \u2014 Pro<\/td>\n<td><code>http.request.uri.path eq \"\/search\"<\/code><\/td>\n<td>30 requests in 60 seconds<\/td>\n<td>Block for 60 seconds<\/td>\n<\/tr>\n<tr>\n<td>Read-only API \u2014 Business<\/td>\n<td><code>http.request.method eq \"GET\" and starts_with(http.request.uri.path, \"\/api\/public\/\")<\/code><\/td>\n<td>50 requests in 10 seconds<\/td>\n<td>Block for 60 seconds; a 429 response for the client<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The login example counts all methods on that path, including GET and POST; it does not specifically count failed passwords. Method matching in rate limiting requires Business or above, so do not append a POST condition to the Free example. Reloads, retries and shared IPs can affect real users. Response-code counting is also a separate supported feature: a 200, 403 or 404 alone does not reliably identify a failed login without understanding the application.<\/p>\n<p>For an interactive login on a plan such as Pro or Business, a supported Managed Challenge action has different behavior from the Block duration above. Free\/Pro\/Business challenge actions use request throttling, with no chosen duration: passing a challenge resets the counter, and exceeding the rate again triggers another challenge. API configurations use <code>mitigation_timeout=0<\/code> for those challenge actions. Do not describe this as a fixed five-minute challenge. Enterprise has additional duration controls.<\/p>\n<h3><span id=\"3_Rate_limiting_for_APIs_and_search\">3. Rate limiting for APIs and search<\/span><\/h3>\n<p>Public APIs, search boxes and product filters are other hot spots for scraping and denial-of-service attempts. Examples:<\/p>\n<ul>\n<li><strong>Search:<\/strong> The table matches the exact path <code>\/search<\/code>. WordPress <code>\/?s=<\/code> is a query-based search on a different path; identify the actual query parameter with fields supported by your plan, or rate limit it in the application.<\/li>\n<li><strong>Public API:<\/strong> Adapt the Business example to the real read-only route. Block defaults to HTTP 429; Pro and above can customize the response, including JSON. The client should handle rate-limit responses and back off. Do not send an HTML browser challenge to a machine client.<\/li>\n<li><strong>Authenticated clients:<\/strong> Apply identity-based allowances only after actual authentication. A user-supplied header or cookie is not itself trusted identity; advanced counting characteristics require the appropriate entitlement.<\/li>\n<li><strong>Contact forms:<\/strong> Combine application-side validation and spam controls with rate limiting based on measured submission patterns; test AJAX handlers and accessibility.<\/li>\n<\/ul>\n<p>Cache eligible public information where appropriate to reduce origin work. Keep personalized cart, checkout and account responses out of shared caching; caching is not a substitute for abuse controls or correct session handling.<\/p>\n<h3><span id=\"4_Rate_limiting_for_checkout_and_payment_flows\">4. Rate limiting for checkout and payment flows<\/span><\/h3>\n<p>Checkout pages and payment APIs can be targets for carding attacks and scripted abuse. At the same time, they are extremely sensitive: you must not block real customers during payment.<\/p>\n<p>Use a separate review for payment flows:<\/p>\n<ul>\n<li>Measure the complete checkout flow, including its AJAX\/API calls, before choosing a limit. A single page can generate many legitimate requests.<\/li>\n<li>Do not automatically challenge cart, checkout APIs or provider webhooks. Verify the browser and non-browser paths independently.<\/li>\n<li>Where necessary, narrow an exception to a verified provider&#8217;s current official network, actual callback path and method. Preserve application-side signature verification; an IP exception is not proof that a payment is valid.<\/li>\n<li>Retain transaction-success and error monitoring so a rule can be reverted if legitimate payments fail.<\/li>\n<\/ul>\n<p>If you operate a larger e-commerce site and care about PCI-DSS in more detail, our guide <a href='https:\/\/www.dchost.com\/blog\/en\/pci-dss-ecommerce-hosting\/'>PCI-DSS compliant e-commerce hosting<\/a> explains how network, logs and TLS all fit together with application-level security.<\/p>\n<h3><span id=\"5_Monitor_rate_limiting_analytics\">5. Monitor rate limiting analytics<\/span><\/h3>\n<p>After you enable rate limiting rules:<\/p>\n<ul>\n<li>Review rule IDs and events alongside application errors and successful login\/checkout rates.<\/li>\n<li>Test legitimate traffic that shares an IP, as well as abusive requests, retries and mobile network changes.<\/li>\n<li>Change thresholds or precise exceptions based on evidence; avoid a general bypass for monitoring or partner traffic.<\/li>\n<\/ul>\n<p>Revisit the limits after major application changes, campaigns and incidents. Keep the reason for each threshold and its rollback step with the rule configuration; an initially quiet week does not establish a permanent safe setting.<\/p>\n<h2><span id=\"Bot_Protection_Separating_Good_Bots_From_Bad_Traffic\">Bot Protection: Separating Good Bots From Bad Traffic<\/span><\/h2>\n<p>Not all bots are bad. Search engines, uptime monitors and payment providers are necessary. The problem is the growing number of malicious or noisy bots: scrapers, credential-stuffing tools, spam bots and vulnerability scanners.<\/p>\n<p>Distinguish Bot Fight Mode, Super Bot Fight Mode and Enterprise Bot Management before using examples. Their configuration and exception capabilities differ.<\/p>\n<h3><span id=\"1_Understand_Cloudflare_bot_scores_and_challenges\">1. Understand Cloudflare bot scores and challenges<\/span><\/h3>\n<p>The numeric <code>cf.bot_management.score<\/code> field requires an <strong>Enterprise plan with the Bot Management add-on<\/strong>. Free, Pro and Business bot products do not grant the same custom-rule field. Evaluated requests have scores from 1 to 99: 1 is high-confidence automation, 2\u201329 is likely automated and 30\u201399 is likely human. <strong>0 means not evaluated<\/strong>, not safe, human or the worst bot. Some requests finish in another Cloudflare feature before Bot Management runs.<\/p>\n<p>With the necessary entitlement, this custom expression selects evaluated low-score requests on a browser login path while excluding verified bots:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">(http.request.uri.path eq &quot;\/wp-login.php&quot;\n and cf.bot_management.score gt 0\n and cf.bot_management.score lt 30\n and not cf.client.bot)<\/code><\/pre>\n<p>Managed Challenge is an action to evaluate for this example. The boundary of 30 follows the documented grouping; it is not a universal safe threshold. Do not extend the same challenge to JSON\/AJAX or machine API paths.<\/p>\n<p>A low score does not prove malicious intent, especially for automated integrations or corporate proxy traffic. Combining low scores with high request frequency on search requires a separate rate limiting rule and counters. Bot Management fields in that rule require Enterprise Bot Management and the relevant rate limiting entitlement; advanced counter keys or complexity-based counting require the corresponding Advanced Rate Limiting capabilities.<\/p>\n<h3><span id=\"2_Use_Bot_Fight_Super_Bot_Fight_Mode_carefully\">2. Use Bot Fight \/ Super Bot Fight Mode carefully<\/span><\/h3>\n<p><strong>Bot Fight Mode<\/strong> is a free domain-wide product that recognizes known bot patterns and can issue computationally expensive challenges. It is not simply a user-agent-based JS Challenge rule. In the current dashboard, open <strong>Security \u2192 Settings<\/strong>, filter by <strong>Bot traffic<\/strong> and go to <strong>Bot fight mode<\/strong>. The product can affect APIs, mobile clients and monitoring as well as unwanted automation.<\/p>\n<ul>\n<li><strong>Bot Fight Mode cannot be skipped with WAF custom rules or Page Rules.<\/strong> An added <code>cf.client.bot<\/code> condition does not bypass it. If it disrupts required traffic, confirm the cause and consider disabling it while selecting a suitable scoped alternative.<\/li>\n<li><strong>Super Bot Fight Mode<\/strong> is included with Pro\/Business and Enterprise without Bot Management. It adds category controls and a custom-rule Skip for its own phase; that Skip does not automatically remove other protections. Turn Bot Fight Mode off when switching.<\/li>\n<li><strong>Categories differ:<\/strong> Pro includes Definitely automated and Verified bots controls; do not assume it has the Likely automated control. If you also use Cloudflare Tunnel, check the documented requirement to keep Definitely Automated set to Allow.<\/li>\n<li><strong>Test:<\/strong> Compare origin request volume and resource use, successful logins, crawler access and real integration behavior. Do not assume a guaranteed bot reduction.<\/li>\n<\/ul>\n<p>Select the bot product according to the exception and visibility requirements of your application. Managed WAF rules, measured rate limits and the chosen bot controls should form one documented policy.<\/p>\n<h3><span id=\"3_Harden_specific_endpoints_against_bots\">3. Harden specific endpoints against bots<\/span><\/h3>\n<p>Use only fields available in the rule type and plan, and distinguish request attributes from a frequency counter:<\/p>\n<ul>\n<li><strong>Login:<\/strong> Use the scoped browser example above where Bot Management is available; an unusual or empty user-agent alone does not establish malicious intent.<\/li>\n<li><strong>Search\/listings:<\/strong> Measure frequency in a rate limiting rule. Apply additional score or ASN conditions only with supporting evidence and the required field entitlement.<\/li>\n<li><strong>Comments\/forms:<\/strong> Combine browser-compatible controls with server-side validation and spam checks. An HTML challenge response can break an AJAX form.<\/li>\n<\/ul>\n<p>If you run WordPress, we shared a lot of practical examples in our article <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-cloudflare-waf-rate-limiting\/'>how Cloudflare WAF and rate limiting can actually stop WordPress bots<\/a> that you can adapt for your own site.<\/p>\n<h3><span id=\"4_Keep_a_clean_allowlist_of_good_bots_and_partners\">4. Keep a clean allowlist of good bots and partners<\/span><\/h3>\n<p>Document which crawlers and partners genuinely need access and which specific rule creates a false positive. Check crawler reports as well as security events; neither the absence of events nor a familiar user-agent guarantees uninterrupted indexing.<\/p>\n<ul>\n<li>Official search engine crawlers<\/li>\n<li>Performance and uptime monitoring tools<\/li>\n<li>Payment gateways, CRM integrations and other APIs that call back to your site<\/li>\n<\/ul>\n<p>Use current official provider identity information and retain application authentication. <code>cf.client.bot<\/code> reports Cloudflare\u2019s known good bot\/crawler classification; it does not classify every required third-party integration. Adding <code>and not cf.client.bot<\/code> narrows only that rule\u2019s match. It does not bypass Bot Fight Mode or the whole WAF. Use a narrowly scoped Super Bot Fight Mode phase Skip or a specific managed-rule exception only where needed, and record its purpose.<\/p>\n<h2><span id=\"A_Practical_Cloudflare_Security_Blueprint_For_Small_Business_Sites\">A Practical Cloudflare Security Blueprint For Small Business Sites<\/span><\/h2>\n<p>Use the following checklist for a small business site at DCHost, adapting it to the actual application, plan and responsibility split.<\/p>\n<h3><span id=\"Step_1_Lock_down_basics\">Step 1: Lock down basics<\/span><\/h3>\n<ul>\n<li>Enable 2FA, review members and use least-privilege API tokens.<\/li>\n<li>Proxy appropriate web records and verify Full (strict) requirements.<\/li>\n<li>Where permitted, restrict origin web access in both address families while preserving management, health checks and renewal. Shared hosting may require provider coordination.<\/li>\n<\/ul>\n<h3><span id=\"Step_2_Turn_on_core_WAF_protection\">Step 2: Turn on core WAF protection<\/span><\/h3>\n<ul>\n<li>Distinguish Free Managed Ruleset from the broader Pro+ rulesets and inspect relevant application tags.<\/li>\n<li>Test supported logging or narrow staging scope; do not assume universal Log\/Simulate or treat a challenge as non-blocking.<\/li>\n<li>Use precise browser login\/admin rules with explicit public-handler and integration treatment. Maintain narrow, correctly ordered exceptions.<\/li>\n<\/ul>\n<h3><span id=\"Step_3_Add_smart_rate_limiting\">Step 3: Add smart rate limiting<\/span><\/h3>\n<ul>\n<li>Use the table\u2019s Free login, Pro search and Business API examples only with their stated fields, periods and rule limits.<\/li>\n<li>Adapt thresholds using normal traffic; shared IPs and counter locality matter.<\/li>\n<li>Handle 429 and challenge-reset behavior correctly. Machine APIs need compatible responses.<\/li>\n<li>Test checkout and authenticated provider callbacks separately; preserve signature checks and personalized-response cache exclusions.<\/li>\n<\/ul>\n<h3><span id=\"Step_4_Layer_bot_protection\">Step 4: Layer bot protection<\/span><\/h3>\n<ul>\n<li>Choose Bot Fight Mode or Super Bot Fight Mode with their actual exception capabilities; do not claim a custom rule skips Bot Fight Mode.<\/li>\n<li>Use numeric bot scores only with Enterprise Bot Management; exclude score 0 from a rule intended for evaluated low-score traffic.<\/li>\n<li>Validate crawler, monitoring, mobile and partner traffic, and keep exceptions narrow.<\/li>\n<\/ul>\n<h3><span id=\"Step_5_Combine_with_server-side_hardening\">Step 5: Combine with server-side hardening<\/span><\/h3>\n<p>Cloudflare is powerful, but you still need basic hygiene on the origin server:<\/p>\n<ul>\n<li>Use ownership and file permissions appropriate to the process model. <a href=\"https:\/\/www.dchost.com\/blog\/en\/linux-file-permissions-644-755-777-explained-for-shared-hosting-and-vps\/\">The Linux file-permission guide<\/a> explains why 644\/755 are contextual examples rather than universal settings.<\/li>\n<li>Keep PHP, CMS, plugins and themes updated; remove unused extensions.<\/li>\n<li>Stage HTTP security headers such as HSTS and CSP and test their effects. See <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-security-headers-hsts-csp\/\">the HTTP security headers guide<\/a>.<\/li>\n<li>Maintain offsite backups and test restoration; having a backup alone does not guarantee rapid recovery.<\/li>\n<\/ul>\n<h3><span id=\"Step_6_Monitor_iterate_document\">Step 6: Monitor, iterate, document<\/span><\/h3>\n<ul>\n<li>Current <strong>Security \u2192 Analytics \u2192 Events<\/strong> shows requests flagged or actioned by security products; Security Analytics covers wider incoming traffic. Events is not a complete access log. Free exposes sampled logs, and sampling may also apply on other plans.<\/li>\n<li>A request can generate multiple events. Compare rule IDs, time, path and available Ray IDs with application logs; edge-blocked requests need not appear at the origin.<\/li>\n<li>Accept restored visitor-IP headers only from a trusted Cloudflare proxy connection; otherwise they can be spoofed.<\/li>\n<li>Test success and rejection paths in staging or narrow scope, then expand gradually. Include forms, checkout, API, mobile, webhook, crawler and monitor clients.<\/li>\n<li>Observe the first 24\u201348 hours and a representative traffic period, then review regularly and after changes. Preserve configuration history and a rollback step.<\/li>\n<\/ul>\n<p>For complementary origin controls, see <a href=\"https:\/\/www.dchost.com\/blog\/en\/the-layered-shield-i-trust-waf-and-bot-protection-with-cloudflare-modsecurity-and-fail2ban\/\">the guide to combining Cloudflare, ModSecurity and Fail2ban<\/a>. Test the behavior of each layer rather than assuming that an exception in one applies to all.<\/p>\n<h2><span id=\"Maintain_a_Measured_Security_Profile\">Maintain a Measured Security Profile<\/span><\/h2>\n<p>A useful Cloudflare security profile starts with supported product capabilities and the real application flow. Begin with a sensitive path, measure legitimate usage and abuse, and expand only after testing. WAF, rate limiting and bot controls can reduce covered attacks and unnecessary origin work; they do not guarantee that a site cannot be compromised or that performance will improve.<\/p>\n<p>Keep the origin updated, use strong authentication and appropriate permissions, and verify restoration from backups. Establish which settings you manage and which are covered by your hosting service. Do not assume Cloudflare zone administration or application optimization is included in every DCHost plan.<\/p>\n<p>When requesting help, include the affected hostname, time, rule ID and available Ray ID so the responsible team can correlate the event. Avoid sharing credentials. Keep the change and rollback documented so the site can be maintained as traffic and features evolve.<\/p>\n<h2><span id=\"Primary_Sources\">Primary Sources<\/span><\/h2>\n<ul>\n<li><a href=\"https:\/\/developers.cloudflare.com\/waf\/managed-rules\/\" rel=\"nofollow noopener\" target=\"_blank\">Cloudflare Managed Rules and plan availability<\/a><\/li>\n<li><a href=\"https:\/\/developers.cloudflare.com\/waf\/rate-limiting-rules\/\" rel=\"nofollow noopener\" target=\"_blank\">Rate limiting availability<\/a> and <a href=\"https:\/\/developers.cloudflare.com\/waf\/rate-limiting-rules\/parameters\/\" rel=\"nofollow noopener\" target=\"_blank\">parameters and action behavior<\/a><\/li>\n<li><a href=\"https:\/\/developers.cloudflare.com\/bots\/concepts\/bot-score\/\" rel=\"nofollow noopener\" target=\"_blank\">Bot scores<\/a> and <a href=\"https:\/\/developers.cloudflare.com\/bots\/get-started\/bot-fight-mode\/\" rel=\"nofollow noopener\" target=\"_blank\">Bot Fight Mode limitations<\/a><\/li>\n<li><a href=\"https:\/\/developers.cloudflare.com\/bots\/get-started\/super-bot-fight-mode\/\" rel=\"nofollow noopener\" target=\"_blank\">Super Bot Fight Mode exceptions<\/a><\/li>\n<li><a href=\"https:\/\/developers.cloudflare.com\/cloudflare-challenges\/challenge-types\/challenge-pages\/\" rel=\"nofollow noopener\" target=\"_blank\">Challenge pages and client compatibility<\/a><\/li>\n<\/ul>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Choose Cloudflare WAF, rate limiting and bot controls that match your plan. Use explicit paths, correct bot-score rules and scoped exceptions, then test customers and integrations.<\/p>\n","protected":false},"author":1,"featured_media":12335,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[184],"tags":[],"class_list":["post-3415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3415"}],"version-history":[{"count":7,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3415\/revisions"}],"predecessor-version":[{"id":12935,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3415\/revisions\/12935"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/12335"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}