Technology

Cloudflare Security Settings Guide: WAF, Rate Limiting and Bot Protection

Many small business owners already use Cloudflare for DNS or CDN, but leave most of the security features at their default values. That usually means you get a bit of protection, but you are far from what Cloudflare can really do for login pages, contact forms, APIs and checkout flows. In this guide, we will walk through how we at dchost.com typically configure Cloudflare Web Application Firewall (WAF), Rate Limiting and Bot Protection for real-world small business websites: corporate sites, blogs, WooCommerce stores, SaaS landing pages and simple client portals. The goal is simple: reduce malicious traffic and automated abuse without frustrating your real customers or breaking your application. We will focus on practical settings, concrete rule examples and a logical order of operations you can copy, then adapt to your own site.

nn

How Cloudflare Fits Into Your Website Security Stack

n

Before touching settings, it helps to be clear about what Cloudflare actually does in your architecture.

n

When your domain is pointed to Cloudflare nameservers, all traffic first hits Cloudflare’s edge network, then Cloudflare forwards allowed requests to your origin server (your hosting account, VPS, dedicated server or colocation machine at dchost.com). This means Cloudflare sits in front of your infrastructure as a reverse proxy.

n

Because of this position, Cloudflare is extremely good at a few things:

n

    n

  • Filtering and scoring HTTP traffic (WAF, bot detection, HTTP headers)
  • n

  • Throttling abusive clients (Rate Limiting and other mitigation rules)
  • n

  • Absorbing and filtering volumetric attacks (DDoS protection)
  • n

n

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 how to secure a VPS server without leaving doors open is a good complement to this guide.

n

In short: think of Cloudflare as a powerful first shield that blocks a large portion of bad traffic before it even reaches your hosting environment.

nn

Baseline Security Hygiene In Cloudflare Before WAF Rules

n

Strong WAF and rate limiting rules are only effective if your account itself is secure and your traffic is properly encrypted. Start with these basics before crafting complex policies.

nn

1. Secure your Cloudflare account

n

    n

  • Enable two-factor authentication (2FA) for all users who can access your Cloudflare account.
  • n

  • Use API tokens with least privilege instead of the global API key whenever tools or scripts need access.
  • n

  • Review account members regularly and remove ex-agency, ex-employee or unused access.
  • n

nn

2. Choose the right SSL/TLS mode

n

Go to SSL/TLS settings and ensure you are using at least ‘Full’ mode, and ideally ‘Full (strict)’ with a valid certificate on the origin. Avoid the old ‘Flexible’ mode because it leaves the connection between Cloudflare and your server unencrypted.

n

For a deeper dive into modern TLS, HSTS and related topics on the server side, see our guide how we configure TLS 1.3, OCSP stapling and HSTS correctly on Nginx and Apache.

nn

3. Protect your origin IP

n

If attackers can bypass Cloudflare and hit your origin IP directly, many of these settings become less effective.

n

    n

  • Restrict direct access to HTTP/HTTPS on the origin so only Cloudflare IP ranges can connect (via firewall rules).
  • n

  • Do not expose your origin IP in DNS records (no stray A records that are set to ‘DNS only’).
  • n

  • For higher security, consider authenticated origin pulls or mTLS between Cloudflare and your origin. We explained this in detail in our article how to protect your origin with Cloudflare authenticated origin pulls and mTLS.

    n

n

Once these basics are solid, you are ready to make the most of Cloudflare WAF, Rate Limiting and Bot Protection.

nn

Configuring Cloudflare WAF For Small Business Websites

n

Cloudflare’s Web Application Firewall is the heart of HTTP-level protection. Properly tuned, it can block most common exploits, bad scanners and generic injections before your application or CMS ever sees them.

n

If you are new to WAFs in general, you can first read our broader overview what is a Web Application Firewall and how Cloudflare WAF and ModSecurity work, then come back here for Cloudflare-specific tuning.

nn

1. Enable and update managed rulesets

n

Under Security → WAF → Managed rules, Cloudflare offers pre-built rulesets written and maintained by their security team.

n

    n

  • Turn on Cloudflare Managed Ruleset at a minimum. This covers OWASP-style attacks like SQL injection, XSS, common CMS probes and more.
  • n

  • If you use a popular CMS such as WordPress, also enable relevant application-specific rules (for example, rules that protect login and XML-RPC endpoints).
  • n

  • Start in ‘Simulate’ mode for new rules if you are worried about false positives, review logs, then switch to ‘Block’.
  • n

n

For most small businesses, Cloudflare’s managed rules alone will block a large volume of noise and opportunistic attacks.

nn

2. Identify your critical URLs first

n

Before creating custom WAF rules, make a short list of your sensitive paths. Common examples:

n

    n

  • Login pages: /wp-login.php, /wp-admin/, /user/login, custom admin URLs
  • n

  • XML-RPC or API endpoints: /xmlrpc.php, /api/, /graphql
  • n

  • E-commerce paths: /cart, /checkout, /my-account
  • n

  • Search endpoints: /?s=, /search, /product-search
  • n

n

These are the URLs that are most often targeted for brute-force, scraping, carding and resource exhaustion. You will use them in custom WAF and rate limiting rules later.

nn

3. Create targeted WAF rules for login and admin areas

n

Generic WAF rules are useful, but targeted rules around login and admin paths often give the biggest win for small businesses.

n

Example rule idea for WordPress logins:

n

    n

  • Expression: URI path equals /wp-login.php or URI path starts with /wp-admin/
  • n

  • Condition: Not known good country (optional) AND not your office IP range (optional)
  • n

  • Action: ‘Managed Challenge’ or ‘JS Challenge’
  • n

n

This adds a light but effective barrier: real users pass once, but basic bots and credential-stuffing scripts often fail.

n

For non-WordPress sites, adjust paths accordingly to your login URL. Avoid using generic patterns that may accidentally include public pages.

nn

4. Use WAF for basic geo and ASN filtering (carefully)

n

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:

n

    n

  • Block or challenge high-risk countries for login, admin and API endpoints.
  • n

  • Challenge suspicious networks (ASNs) known for data-center hosting when they access consumer-facing pages like login or checkout.
  • n

n

Be careful: complete geo-blocking for the entire site can cause real issues if you have travelling customers, foreign search engines or cross-border partners. Use geo filters mainly for sensitive endpoints and with ‘Challenge’ actions first, not immediate block.

nn

5. Log, test and tune for false positives

n

Whenever you add or change rules:

n

    n

  • Start with ‘Log’ or ‘Simulate’ where available.
  • n

  • Watch the Security → Events view for 24–72 hours.
  • n

  • When you see an entry that looks legitimate, click into it and note which rule fired.
  • n

  • Adjust the rule expression (for example, exclude your payment gateway IPs or internal API calls) rather than disabling the entire managed rule.
  • n

n

This iterative, data-driven approach keeps protection strong without breaking key user flows like payments, login or form submissions.

nn

Rate Limiting: Stopping Abuse Without Hurting Real Users

n

WAF looks at what a request contains. Rate limiting looks at how often a client hits certain endpoints. Together, they are extremely effective against brute-force attacks, scraping and simple denial-of-service attempts.

n

Cloudflare’s current interface may expose ‘Rate Limiting Rules’ or ‘Rate Limiting’ under different names depending on your plan, but the ideas are the same: define a URL pattern, a threshold, a period and an action.

nn

1. Basic concepts to keep in mind

n

    n

  • Threshold: How many requests are allowed in a given time window.
  • n

  • Period: The time window in seconds (for example, 10 seconds, 1 minute, 10 minutes).
  • n

  • Action: Block, challenge, or sometimes serve cached content.
  • n

  • Scope: Usually per IP address, but can be per session or per combination depending on advanced rules.
  • n

n

The art is choosing thresholds high enough that normal users and search engines are not impacted, but low enough to catch abusive patterns.

nn

2. Rate limiting for login pages

n

Login endpoints are ideal candidates for rate limiting. Here is a practical pattern that works well for many small business WordPress and custom sites:

n

    n

  • URL pattern: /wp-login.php* or your custom login path
  • n

  • Threshold: 5–10 requests per 10 seconds per IP
  • n

  • Action: Block or Challenge for 5–15 minutes
  • n

  • Response code filter (optional): Only count responses with 200/403/404 status to avoid weird edge cases
  • n

n

This will not affect real users who type a password once or twice, but stops scripts that hammer the login form dozens of times per second.

n

If you run a membership or SaaS app with heavy login usage, start more conservatively (for example 20 requests per 30 seconds) and monitor logs before tightening.

nn

3. Rate limiting for APIs and search

n

Public APIs, search boxes and product filters are other hot spots for scraping and denial-of-service attempts. Examples:

n

    n

  • Search endpoints: Limit queries like /?s= or /search to maybe 30–60 requests per minute per IP.
  • n

  • Public JSON or REST APIs: For anonymous usage, consider 60–120 calls per minute per IP, with dedicated higher limits for authenticated clients or trusted IP ranges.
  • n

  • Contact forms: Protect /contact or AJAX form endpoints with both CAPTCHAs and light rate limiting to slow spammers.
  • n

n

Combine rate limiting with application-level caching where possible so that well-behaved users and bots can still be served quickly without hammering your origin.

nn

4. Rate limiting for checkout and payment flows

n

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.

n

We usually recommend:

n

    n

  • Using Cloudflare WAF + bot detection challenges as the first line on cart and checkout URLs.
  • n

  • Adding gentle rate limits, for example 20–30 requests per minute per IP, and monitoring logs closely.
  • n

  • Excluding your payment provider IPs from these limits if they call back to your site for webhooks.
  • n

n

If you operate a larger e-commerce site and care about PCI-DSS in more detail, our guide PCI-DSS compliant e-commerce hosting explains how network, logs and TLS all fit together with application-level security.

nn

5. Monitor rate limiting analytics

n

After you enable rate limiting rules:

n

    n

  • Check Cloudflare analytics and Security → Events to see which rules fire most often.
  • n

  • Watch for complaints from real users about ‘site not loading’ around login or checkout flows.
  • n

  • Adjust thresholds or add exclusions for office IPs, monitoring tools and payment gateways.
  • n

n

It is completely normal to tweak these values several times in the first week. Once tuned, they often run for months with very little maintenance.

nn

Bot Protection: Separating Good Bots From Bad Traffic

n

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.

n

Cloudflare offers multiple layers of bot protection, depending on your plan, but the general tactics are similar for all small business sites.

nn

1. Understand Cloudflare bot scores and challenges

n

Cloudflare assigns a ‘bot score’ to each request based on behaviour, fingerprints and machine learning. You can then write rules that apply different actions based on that score, such as:

n

    n

  • Allow high-trust bots (for example, search engines, performance crawlers)
  • n

  • Challenge medium-trust traffic with JavaScript or managed challenges
  • n

  • Block or challenge very low-score traffic, especially on sensitive endpoints
  • n

n

For many small sites, a simple policy like ‘challenge low-score bots on login, admin and search URLs’ significantly reduces noise.

nn

2. Use Bot Fight / Super Bot Fight Mode carefully

n

Cloudflare’s ‘Bot Fight’ and advanced bot modes can aggressively block automated traffic. They are effective, but you must watch for side effects:

n

    n

  • Start with ‘Definitely automated’ categories rather than ‘Likely automated’ to avoid catching edge cases.
  • n

  • Always create allowlists for your uptime monitors, SEO tools and any 3rd party services that need to crawl your site.
  • n

  • Monitor logs in the first days to verify that major search engines are not negatively affected.
  • n

n

The best combination is usually: managed WAF rules + gentle rate limits + targeted bot challenges, rather than relying on a single magic switch.

nn

3. Harden specific endpoints against bots

n

Combine WAF fields like user agent, bot score, method and path to protect your most abused endpoints:

n

    n

  • Login URLs: Challenge requests with low bot scores and strange or empty user agents.
  • n

  • Search and listing pages: Challenge high-frequency scraping from data-center IP ranges (ASNs) while allowing normal users.
  • n

  • Comment and contact forms: Combine bot challenges with server-side spam filters and tools like reCAPTCHA.
  • n

n

If you run WordPress, we shared a lot of practical examples in our article how Cloudflare WAF and rate limiting can actually stop WordPress bots that you can adapt for your own site.

nn

4. Keep a clean allowlist of good bots and partners

n

To avoid hurting SEO, analytics or integrations, maintain a small, documented list of trusted bots and IP ranges that should bypass some protections:

n

    n

  • Official search engine crawlers
  • n

  • Performance and uptime monitoring tools
  • n

  • Payment gateways, CRM integrations and other APIs that call back to your site
  • n

n

For each, confirm their official IP list or user agent documentation, then implement precise allow rules in Cloudflare. Never rely on random blog posts or unverified IP ranges.

nn

A Practical Cloudflare Security Blueprint For Small Business Sites

n

Let us put everything together into a realistic configuration you can apply to most small business sites hosted at dchost.com: a WordPress corporate site, a brochure site with a contact form, or a WooCommerce store with moderate traffic.

nn

Step 1: Lock down basics

n

    n

  • Enable 2FA and tighten account access.
  • n

  • Set SSL/TLS mode to ‘Full (strict)’ with a valid origin certificate.
  • n

  • Restrict direct access to your origin IP at the firewall level so only Cloudflare can reach HTTP/HTTPS.
  • n

nn

Step 2: Turn on core WAF protection

n

    n

  • Enable Cloudflare Managed Ruleset and the relevant CMS-specific rules.
  • n

  • Start in ‘Simulate’ where available, review logs for a couple of days, then switch high-confidence rules to ‘Block’.
  • n

  • Create a dedicated WAF rule that challenges access to your login and admin URLs from unknown countries and networks.
  • n

nn

Step 3: Add smart rate limiting

n

    n

  • Login endpoints: 5–10 requests per 10 seconds per IP, block or challenge for 10–15 minutes on violation.
  • n

  • Search endpoints: 30–60 requests per minute per IP, ideally with some caching.
  • n

  • APIs: 60–120 requests per minute per IP, with higher limits for authenticated or partner traffic.
  • n

  • Checkout: gentle limits and strong logging; exclude payment provider IPs from strict rules.
  • n

nn

Step 4: Layer bot protection

n

    n

  • Enable Cloudflare’s bot protection features at a conservative level.
  • n

  • Create rules that challenge low bot-score traffic on login, search and form endpoints.
  • n

  • Maintain an allowlist for search engines, uptime monitors and critical integrations.
  • n

nn

Step 5: Combine with server-side hardening

n

Cloudflare is powerful, but you still need basic hygiene on the origin server:

n

    n

  • Use secure file permissions and separate users, especially on VPS and dedicated servers. Our article Linux file permissions for shared hosting and VPS walks through safe defaults like 644 and 755.
  • n

  • Keep PHP, CMS, plugins and themes updated, and disable or remove unused extensions.
  • n

  • Configure HTTP security headers such as HSTS, CSP and X-Frame-Options on the origin. For a practical walkthrough, see our HTTP security headers guide.
  • n

  • Have regular, automated backups with offsite copies so you can recover from any incident quickly.
  • n

nn

Step 6: Monitor, iterate, document

n

    n

  • Check Cloudflare Security → Events weekly to see which rules fire most and adjust thresholds when needed.
  • n

  • After each major website change (new plugin, new checkout flow, new API), re-test critical paths through Cloudflare to ensure nothing is blocked.
  • n

  • Document your rules and the reasoning behind them so your team or agency can maintain them without guesswork.
  • n

n

If you want to go even further with a layered approach that mixes Cloudflare, ModSecurity on the server and tools like Fail2ban, you may find our article how we layer WAF and bot protection with Cloudflare, ModSecurity and Fail2ban useful as a next step.

nn

Conclusion: Turn Cloudflare Into a Real Shield For Your Business

n

Cloudflare can be much more than a DNS host or a free CDN. When you take the time to configure WAF rules, rate limiting and bot protection in a structured way, it becomes a real security layer in front of your hosting: stopping common attacks, absorbing noisy traffic and giving your origin server room to breathe. For small businesses, the right settings often mean fewer hacked sites, fewer spammy form submissions, less login abuse and a smoother experience for legitimate visitors.

n

At dchost.com, we see the best results when Cloudflare is combined with a solid hosting foundation: up-to-date software, secure file permissions, well-tuned PHP and database settings, and a serious backup strategy. If you host your site, VPS, dedicated server or colocated hardware with us, our team can help you review both your origin configuration and your Cloudflare zone so they work together instead of against each other.

n

If you are unsure where to start, pick one area from this guide—such as login protection with WAF and rate limiting—apply the recommended rules, and observe the impact for a week. From there, expand step by step. And if you would like a second pair of eyes on your setup, reach out to our support team at dchost.com; we are happy to help you turn Cloudflare into a quiet, reliable shield for your business website.

Frequently Asked Questions

Yes. Cloudflare sits in front of your origin and filters a large portion of HTTP traffic, but it cannot replace a host-based firewall or operating system hardening. You should still restrict SSH and control panel access, close unused ports, patch the OS and services, and use tools like iptables or nftables on VPS and dedicated servers. Ideally, you only allow HTTP/HTTPS from Cloudflare IP ranges to your origin, and manage everything else (SSH, database, mail) over restricted IPs or VPN. This layered approach means that even if one layer is misconfigured or bypassed, the others still protect your infrastructure.

The right thresholds depend heavily on your traffic patterns and application. As a rule of thumb, start conservative: for login pages, allow 5–10 requests per 10 seconds per IP; for search and public APIs, consider 30–60 requests per minute per IP. Monitor Cloudflare's Security and Analytics panels and collect feedback from users. If you see no issues and attackers are still slipping through, tighten the thresholds gradually. If you run high-traffic sites or APIs, segment traffic by path and authentication status, giving trusted or logged-in users higher limits and using stricter rules for anonymous or suspicious traffic.

When configured properly, Cloudflare should not hurt SEO. The key is to maintain a clear allowlist of major search engine crawlers and not to apply aggressive blocking to the entire site. Focus strict WAF and bot rules on sensitive endpoints like login, admin, search and checkout, rather than on all URLs. Start with 'Challenge' actions instead of 'Block' when you are unsure, and review Cloudflare logs to verify that search engine requests are allowed. If you notice any indexing issues, check the user agent and IP ranges against the search engine’s official documentation and adjust your rules accordingly.

Use Cloudflare’s simulation features wherever possible. For managed rules, enable them in 'Simulate' or 'Log' mode first, which records matches without blocking. For custom WAF expressions, you can initially set the action to 'Log' or a non-blocking challenge and watch Security → Events to see what would have been blocked. Test key user journeys yourself: homepage, product pages, search, login, checkout and contact forms. Only after 24–72 hours of clean logs and successful tests should you switch high-confidence rules to 'Block'. Document changes and be prepared to rollback or relax a specific rule if issues appear.

Cloudflare dramatically reduces many attack vectors on WordPress, especially brute-force logins, common exploits and generic scanning. However, it is not a silver bullet. You still need to keep WordPress core, themes and plugins updated, remove unused plugins, use strong passwords and 2FA, lock down file permissions and maintain reliable backups. Combining Cloudflare WAF and rate limiting with good server-side practices and sensible security plugins creates a much stronger overall posture. If your WordPress site is hosted with dchost.com, our team can also help you tune PHP-FPM, database and caching settings so security and performance work together.