How to use Cloudflare to protect your website?

You use Cloudflare to protect your website by moving your domain's DNS to Cloudflare, turning on the orange-cloud proxy for your web records, and then configuring its security features: Full (strict) SSL, the web application firewall, bot protection, rate limiting, and DDoS mitigation. The final and most overlooked step is locking down your origin server so attackers can't simply bypass Cloudflare and hit your host directly.

Cloudflare sits between your visitors and your server, which means every request passes through its network before it reaches you. That position lets it filter malicious traffic, absorb floods, and cache content, often on the free plan. This guide walks you through the setup in a sensible order, explains which settings matter most, gives you example firewall rules you can adapt, and shows how to make sure your origin only accepts traffic from Cloudflare.

How Cloudflare Protects a Website

When you proxy a DNS record through Cloudflare, your domain resolves to Cloudflare's IP addresses instead of your server's. Visitors connect to the nearest Cloudflare data centre, Cloudflare inspects the request, and only then forwards it to your origin.

This reverse-proxy model gives you several layers of defence:

• DDoS mitigation: Large volumetric attacks are absorbed by Cloudflare's network instead of your hosting account. Unmetered DDoS protection is included on all plans.
• Web application firewall (WAF): Requests matching known attack patterns, such as SQL injection or cross-site scripting attempts, can be blocked before they reach your application.
• Bot management: Automated traffic can be challenged or blocked based on behaviour and reputation.
• Rate limiting: Excessive requests to sensitive endpoints, like login pages, can be throttled.
• IP hiding: Your origin's real IP address isn't published in DNS, which makes direct attacks harder.
• TLS everywhere: Cloudflare provides free certificates and can enforce HTTPS for every visitor.

It's worth being clear about what Cloudflare doesn't do. It won't patch a vulnerable plugin, fix a weak admin password, or clean up malware already on your server. It's a strong outer wall, not a replacement for keeping your application secure.

Step 1: Add Your Site and Move DNS to Cloudflare

1. Create an account: Sign up at Cloudflare and enable two-factor authentication on the account straight away. Whoever controls this account controls your site's traffic.
2. Add your domain: Enter your domain and choose a plan. The free plan covers the essentials for most small sites.
3. Review imported DNS records: Cloudflare scans your existing DNS. Check that every record is present, especially MX, TXT (SPF, DKIM, DMARC), and any verification records.
4. Change your nameservers: At your domain registrar, replace the existing nameservers with the two Cloudflare nameservers you're given. Propagation typically takes anywhere from a few minutes to a day.

Orange Cloud vs Grey Cloud

Each DNS record has a proxy status:

• Proxied (orange cloud): Traffic flows through Cloudflare and gets all the protection features. Use this for your website's A, AAAA, and CNAME records, such as the root domain and www.
• DNS only (grey cloud): Cloudflare just answers DNS queries. Use this for mail servers, FTP or SSH hostnames, and anything that isn't HTTP or HTTPS traffic.

A common mistake is leaving a record like ftp.example.com or cpanel.example.com grey-clouded while it points to the same server as your website. That exposes your origin IP to anyone who looks it up, which undermines the protection you're setting up. If you need those services, consider using a different IP, restricting them by firewall, or using Cloudflare Tunnel (covered later).

Step 2: Configure SSL/TLS Correctly

Go to SSL/TLS > Overview and set the encryption mode. This single setting matters a lot:

1. Off: No HTTPS. Never use this.
2. Flexible: Visitors connect to Cloudflare over HTTPS, but Cloudflare connects to your server over plain HTTP. It looks secure in the browser but traffic to your origin is unencrypted, and it frequently causes redirect loops on WordPress.
3. Full: Encrypted to your origin, but the origin certificate isn't validated.
4. Full (strict): Encrypted to your origin with a valid certificate. This is the one you want.

For Full (strict), your origin needs a valid certificate. You can use a Let's Encrypt certificate from your host, or generate a free Cloudflare Origin CA certificate under SSL/TLS > Origin Server and install it on your server. Origin CA certificates are only trusted by Cloudflare, which is fine because visitors never connect to your origin directly.

Then under SSL/TLS > Edge Certificates, turn on:

• Always Use HTTPS: Redirects all HTTP requests to HTTPS.
• Minimum TLS Version: Set to TLS 1.2. Very old clients will be excluded, but that's an acceptable trade-off for most sites.
• Automatic HTTPS Rewrites: Helps fix mixed content by rewriting HTTP links to HTTPS where possible.
• HSTS: Only enable this after you're certain every subdomain works over HTTPS, because browsers will refuse HTTP for the duration you set. Start with a short max-age.

Step 3: Turn On the Managed Security Features

Cloudflare's dashboard layout changes from time to time, but the core features are found under the Security section of your domain.

Bot Fight Mode

Under Security > Bots, the free plan offers Bot Fight Mode, which challenges requests from known bad bots. Paid plans have Super Bot Fight Mode with more granular control. Test your site after enabling it, because it can occasionally interfere with legitimate automated tools like uptime monitors or payment webhooks. If that happens, you may need to add a skip rule for those services.

Managed WAF Rules

Free plans include the Cloudflare Free Managed Ruleset, which covers a set of high-impact vulnerabilities. Pro and higher plans unlock the full Cloudflare Managed Ruleset and the OWASP Core Ruleset, which cover a much wider range of attack patterns and include rules targeting popular platforms such as WordPress. If your site handles logins, payments, or customer data, the Pro plan's managed rules are often worth it.

Security Level and Challenge Passage

Security Level controls how aggressively Cloudflare challenges visitors with poor IP reputation. The default is fine for most sites. Leave it there and use targeted custom rules rather than raising it site-wide, which can annoy real visitors.

Under Attack Mode

If you're actively being hit by a layer 7 DDoS attack, Under Attack Mode shows every visitor a brief JavaScript challenge before they reach your site. It's an emergency switch, not an everyday setting, so turn it off once the attack subsides.

Step 4: Write Custom WAF Rules

Custom rules are where Cloudflare becomes really useful. Go to Security > WAF > Custom rules and create rules using the expression builder or the expression editor. The free plan allows a handful of custom rules, so prioritise the most valuable ones.

Protect the WordPress Login and Admin Area

This rule challenges requests to the login page and admin area unless they come from your own IP address. Replace the IP with yours:

(http.request.uri.path eq "/wp-login.php" or starts_with(http.request.uri.path, "/wp-admin"))
and not starts_with(http.request.uri.path, "/wp-admin/admin-ajax.php")
and ip.src ne 203.0.113.10

Set the action to Managed Challenge. Excluding admin-ajax.php is important because many themes and plugins use it for front-end features. If you have a static IP, you could choose Block instead, but make sure you won't lock yourself out when working from elsewhere.

Block XML-RPC If You Don't Use It

If you don't use the WordPress mobile app, Jetpack, or remote publishing tools, XML-RPC is mostly an attack surface:

(http.request.uri.path eq "/xmlrpc.php")

Action: Block.

Challenge Traffic From Countries You Don't Serve

If your business only serves customers in specific countries, you can challenge the rest instead of blocking them outright:

(not ip.src.country in {"GB" "US" "CA"} and not cf.client.bot)

Action: Managed Challenge. The cf.client.bot field allows verified good bots like search engine crawlers through, so your SEO isn't affected.

Block Common Probing Paths

Automated scanners constantly probe for exposed files. A rule like this cuts down the noise:

(http.request.uri.path contains "/.env")
or (http.request.uri.path contains "/.git")
or (ends_with(http.request.uri.path, ".sql"))
or (ends_with(http.request.uri.path, ".bak"))

Action: Block. You should still make sure these files don't exist in your web root, but this adds a layer.

Step 5: Add Rate Limiting to Sensitive Endpoints

Rate limiting rules live under Security > WAF > Rate limiting rules. The free plan includes one rule with basic options, which is best spent on your login page.

A sensible starting rule:

1. Match: http.request.uri.path eq "/wp-login.php" and request method is POST.
2. Rate: A small number of requests per 10-second or 1-minute window from the same IP. Start conservatively, such as 5 requests per minute.
3. Action: Block or Managed Challenge.
4. Duration: Block for the period your plan allows.

The same approach works for other sensitive paths, like /api/login, password reset endpoints, or checkout forms. Adjust the thresholds based on real traffic patterns, and watch Security > Events to make sure legitimate users aren't getting caught.

Step 6: Lock Down Your Origin Server

This is the step that turns Cloudflare from "helpful" into "effective". If attackers can find your origin IP, from old DNS records, historical lookups, email headers, or a grey-clouded subdomain, they can send traffic straight to your server and skip every rule you've written.

Option A: Allow Only Cloudflare IP Ranges

Cloudflare publishes its IP ranges at https://www.cloudflare.com/ips/. You can configure your server firewall to accept HTTP and HTTPS only from those ranges. On an Ubuntu server with UFW, a script like this does it:

#!/usr/bin/env bash
# Allow HTTP/HTTPS only from Cloudflare. Keep an SSH session open while testing.
set -euo pipefail

for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443 comment 'Cloudflare'
done

# Remove any general rules that allow web traffic from anywhere
sudo ufw delete allow 80/tcp || true
sudo ufw delete allow 443/tcp || true
sudo ufw delete allow 'Nginx Full' || true

sudo ufw status numbered

Make sure your SSH rule stays in place before running anything like this, and keep your current session open until you've confirmed you can still connect. Cloudflare's ranges change occasionally, so review them periodically. On shared hosting, where you don't control the firewall, ask your host whether they support Cloudflare-only access.

Option B: Authenticated Origin Pulls

With Authenticated Origin Pulls (under SSL/TLS > Origin Server), Cloudflare presents a client certificate when it connects to your server, and your server rejects connections without it. In Nginx, after downloading Cloudflare's origin pull CA certificate:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/cloudflare/origin.pem;
    ssl_certificate_key /etc/ssl/cloudflare/origin.key;

    ssl_client_certificate /etc/ssl/cloudflare/authenticated_origin_pull_ca.pem;
    ssl_verify_client on;

    # ... rest of your site configuration
}

Option C: Cloudflare Tunnel

Cloudflare Tunnel runs a small daemon called cloudflared on your server that makes an outbound connection to Cloudflare. Your server then needs no open inbound web ports at all. It's the strongest option for VPS setups and also works well for exposing internal tools securely.

Restore Real Visitor IPs

Once traffic comes through Cloudflare, your server logs and security plugins see Cloudflare's IPs instead of your visitors'. Cloudflare passes the original IP in the CF-Connecting-IP header. In Nginx, the ngx_http_realip_module handles this:

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... add every range from https://www.cloudflare.com/ips/
real_ip_header CF-Connecting-IP;

For Apache, mod_remoteip does the same using RemoteIPHeader CF-Connecting-IP and RemoteIPTrustedProxy lines. Only trust this header from Cloudflare's ranges, otherwise anyone could fake their IP.

Other Useful Cloudflare Security Settings

• Cloudflare Access (Zero Trust): Put your admin area or staging site behind a login screen that requires your identity provider or a one-time code. The Zero Trust free tier covers small teams.
• Page Shield / script monitoring: On supported plans, this alerts you when new third-party scripts appear on your pages, which helps catch card-skimming injections.
• DNSSEC: Under DNS > Settings, enable DNSSEC and add the DS record at your registrar to protect against DNS spoofing.
• Account security: Use two-factor authentication, give team members scoped roles rather than sharing one login, and create API tokens with minimal permissions instead of using the Global API Key.

Testing and Monitoring

After setting things up:

1. Browse your site logged out and logged in, and test forms, checkout, and any integrations.
2. Check Security > Events to see what's being blocked or challenged, and tune rules that catch legitimate traffic.
3. Confirm the origin is hidden by trying to load your server's IP directly in a browser. It should refuse the connection or return nothing useful.
4. Verify certificates by checking that Full (strict) works without errors.

---

FAQ: Using Cloudflare to Protect Your Website

---

Conclusion

Cloudflare gives you an impressive amount of protection for very little effort: DDoS absorption, free certificates, a managed firewall, bot filtering, and rate limiting, all in front of your server. The key is configuring it thoughtfully. Use Full (strict) SSL, proxy your web records, write a few targeted rules for your login and admin areas, and make sure sensitive endpoints are rate limited.

Most importantly, don't leave the back door open. Lock your origin so it only accepts traffic from Cloudflare, keep your Cloudflare account itself protected with two-factor authentication, and review the security events regularly. Combined with good security habits on your site itself, Cloudflare becomes a reliable first line of defence.