Turning on Cloudflare takes ten minutes: change the nameservers, wait, and the site is suddenly behind a global network with DDoS protection and a padlock in the browser. That ease is also why so many setups stop halfway. We regularly see sites behind Cloudflare whose server IP can still be reached directly, whose traffic to the server is not encrypted at all, or whose payment callbacks fail because a bot filter was switched on without checking. This guide covers what Cloudflare and its web application firewall really do, which plan fits which kind of site, and how to set it up so the protection is not only on paper.
What Happens When You Put Cloudflare in Front of a Website
After the domain's nameservers point to Cloudflare, every DNS record marked Proxied (the orange cloud) sends visitors to Cloudflare first. Cloudflare then forwards the request to your own server, which it calls the origin. Records marked DNS only (the grey cloud) are not protected at all: they simply return your server's IP address. Mail, SSH, and FTP subdomains are usually left as DNS only, and that is fine, as long as you understand what it reveals.
Because the traffic passes through Cloudflare, it can do several jobs at once: cache static files close to visitors, absorb DDoS attacks, handle HTTPS, filter requests through the WAF, and challenge suspicious bots. Cloudflare has points of presence in Jakarta and connects with many local networks, so for visitors in Indonesia the extra hop usually costs little, and cached pages often load faster than they would straight from the origin.
What a WAF Does, and What It Cannot Do
A web application firewall reads each HTTP request, including the URL, headers, cookies, and body, and compares it with a set of rules. Requests that look like SQL injection, cross-site scripting, path traversal, or an exploit for a known vulnerability are blocked or challenged before they reach the application. A network firewall such as iptables or an AWS security group only sees IP addresses and ports, so it cannot tell an ordinary login from a login that carries a SQL injection payload.
The most valuable thing a managed WAF gives a small team is time. When React2Shell (CVE-2025-55182), a remote code execution flaw in React Server Components, was disclosed in December 2025, Cloudflare added a blocking rule to its managed rulesets within a day, including the Free Managed Ruleset that free-plan sites get by default. Sites behind it were covered while their developers were still upgrading React and Next.js. This is usually called virtual patching.
What a WAF does not understand is your business logic. It cannot know that user A should not open user B's invoice by changing an ID in the URL, that a voucher code may only be used once, or that a staff account should not reach an admin endpoint. These access control flaws are the most common serious findings in penetration tests, and only the application can fix them. Managed rules can also be bypassed by unusual payloads, and they only inspect part of very large request bodies.
A WAF buys time between the day a vulnerability is announced and the day you patch it. It does not replace the patch, and it does not replace fixing your own code.
Free, Pro, Business, Enterprise: What Each Plan Includes
| Feature | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Price per domain per month | $0 | $20 billed annually, $25 billed monthly | $200 billed annually, $250 billed monthly | Custom contract |
| Managed WAF rules | Free Managed Ruleset for critical, widely exploited vulnerabilities | Cloudflare Managed Ruleset and OWASP Core Ruleset | The same rulesets as Pro | All rulesets, plus add-ons such as API Shield |
| Custom WAF rules | 5 | 20 | 100, with regex support | 1,000 |
| Rate limiting rules | 1 rule, counted per IP over 10 seconds | 2 rules, windows up to 1 minute | 5 rules, windows up to 10 minutes | Up to 100 rules, with more counting options |
| Bot protection | Bot Fight Mode for simple bots | Super Bot Fight Mode | Super Bot Fight Mode with bot analytics | Bot Management with per-request bot scores |
| Leaked credential detection | Checks whether the password is known to be leaked | Checks the username and password pair | Same checks as Pro | Additional detections and custom locations |
| Support and SLA | Community forum, no SLA | Email tickets, no SLA | Tickets and chat, 100% uptime SLA | 24/7 phone, chat, and tickets, SLA with larger credits |
Prices are per domain, so three websites on Pro cost three times as much. DDoS protection is unmetered on every plan, including Free, which means you are not billed extra or cut off because of an attack. The figures above come from Cloudflare's plan pages and documentation in November 2026. Cloudflare changes its packaging often, so check the current page before you budget.
Which Plan Fits Which Site
- Free is enough for a company profile, a blog, landing pages, and small internal tools. You still get DDoS protection, the Free Managed Ruleset, five custom rules, one rate limiting rule, Turnstile as a CAPTCHA replacement, and Cloudflare Tunnel.
- Pro is worth it as soon as the site has logins, forms that write to a database, or an online shop, and for any WordPress site with many plugins. The Cloudflare Managed Ruleset and the OWASP Core Ruleset catch far more attack patterns than the free ruleset, and $20 a month is less than one hour of cleaning up a hacked site.
- Business makes sense when you need an uptime SLA, chat support, regex in rules, longer rate limiting windows, or help with PCI DSS requirements for card payments.
- Enterprise is for banks, fintech, and large platforms that need advanced bot management, a named support contact, contractual terms about data location, or reports for OJK and auditors.
Setting Up Cloudflare Correctly
- 1Add the domain and let Cloudflare import the existing DNS records. Before changing nameservers, compare the result line by line with the old DNS zone, especially MX records and the TXT records for SPF, DKIM, DMARC, and domain verification. A missing record usually shows up as email that silently stops arriving.
- 2Change the nameservers at your registrar. For .id domains this is done in the panel of the registrar where you bought the domain. The change usually takes effect within a few hours.
- 3Decide which records are proxied. Website records such as the root domain, www, and app should be Proxied. Mail, SSH, FTP, and database hosts should be DNS only, because the proxy only handles HTTP and HTTPS on a limited set of ports.
- 4Set the SSL/TLS mode to Full (strict) and install a valid certificate on the origin, either a free Let's Encrypt certificate or a Cloudflare Origin CA certificate, which can be valid for up to 15 years but is trusted only by Cloudflare, not by browsers. Then turn on Always Use HTTPS.
- 5Restore the real visitor IP on the server. Without this, your access logs, fail2ban, and the application's own rate limiting only see Cloudflare's addresses. In Nginx, add a set_real_ip_from line for each Cloudflare IP range and set real_ip_header CF-Connecting-IP.
- 6Lock the origin. Allow ports 80 and 443 only from Cloudflare's published IP ranges at cloudflare.com/ips, in the server firewall or the cloud security group. A cleaner option is Cloudflare Tunnel: the cloudflared agent connects outward to Cloudflare, so the server needs no open inbound web ports at all. Authenticated Origin Pulls adds a client certificate check on top.
- 7Check the WAF settings. On Free, make sure the Free Managed Ruleset is active. On Pro and above, deploy the Cloudflare Managed Ruleset and the OWASP Core Ruleset. Start the OWASP ruleset at a low paranoia level and a high anomaly score threshold, then tighten it once you know what normal traffic looks like.
- 8Read Security Events every day for the first week. This is where you see which requests were blocked and why, and it is the only way to catch rules that block real customers.
Custom Rules Worth Having
The free plan only has five custom rules, so spend them on what matters. Rules are written as expressions in the dashboard. The examples below use Cloudflare's rule language, and the paths and IP addresses should be adjusted to your own application.
- Protect the admin login. For WordPress: (http.request.uri.path contains "/wp-login.php" or (http.request.uri.path contains "/wp-admin" and not http.request.uri.path contains "/admin-ajax.php")) and not ip.src in {203.0.113.10}, with the action Managed Challenge or Block. Excluding admin-ajax.php matters, because many themes and plugins call it from public pages.
- Block xmlrpc.php if you do not use it: http.request.uri.path eq "/xmlrpc.php", action Block. It is a favourite target for password guessing. Check first whether Jetpack or a mobile publishing app depends on it.
- Limit an admin panel to Indonesia when all your staff are here: http.request.uri.path contains "/admin" and ip.src.country ne "ID", action Managed Challenge. This does not stop a determined attacker using a local VPN, but it removes most automated noise.
- Block probes for files that should never be public: http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git", action Block. Bots scan for these all day, and one exposed .env file can leak database and API credentials.
- Challenge logins with leaked passwords. After enabling leaked credentials detection, a rule on the login path with cf.waf.credential_check.password_leaked and the action Managed Challenge slows down credential stuffing. This field is available on the free plan.
Use your one free rate limiting rule on the endpoint that hurts most when abused. That is usually the login page or the endpoint that sends an OTP, because every OTP sent over SMS or WhatsApp costs money. A rule such as more than 5 requests in 10 seconds from one IP to /api/auth/otp is a reasonable start. The free plan only allows a 10-second window and a 10-second block, so keep limits in the application as well, for example a maximum number of OTP requests per phone number per hour.
Mistakes We Often Find
- Flexible SSL. The browser shows a padlock, but traffic between Cloudflare and the server travels as plain HTTP. If the server also redirects HTTP to HTTPS, the site ends in an endless redirect loop with ERR_TOO_MANY_REDIRECTS. Use Full (strict).
- The origin IP is still known. Old A records from before Cloudflare, an MX record pointing to the same server, a forgotten DNS-only subdomain, or internet scanners that index the server's certificate can all reveal the IP. An attacker who knows it skips Cloudflare entirely. Lock the origin as described above, and if the IP has already leaked, move to a new one.
- Bot Fight Mode breaks webhooks and mobile apps. Callbacks from payment gateways, WhatsApp API webhooks, and API calls from your own mobile app can be challenged, and a challenge means the request fails. On the free plan, Bot Fight Mode applies to the whole domain and custom rules cannot skip it. Only IP Access rules, which are evaluated first, can exempt known partner IPs. If you cannot list them, leave Bot Fight Mode off and rely on targeted custom rules.
- Caching pages that belong to one user. A Cache Everything rule on a site with logins can serve one customer's account page or cart to another customer. Bypass the cache for logged-in sessions, the cart, checkout, and all API paths.
- Leaving Under Attack Mode on for weeks. Every visitor waits for an interstitial check, conversion drops, and API clients break. Turn it on during an attack and off again afterwards, or apply challenges only to the paths being attacked.
- Never looking at Security Events. OWASP rules can block a content editor from saving an article that contains HTML or code, and nobody notices until someone complains. Review blocked requests regularly and add narrow exceptions instead of switching whole rulesets off.
- Blocking AI crawlers without meaning to. Since July 2025, Cloudflare blocks known AI crawlers by default on newly added domains. Search engine crawlers such as Googlebot are not affected, but if you want your content to appear in AI assistants, review the AI crawler settings in the dashboard.
Cloudflare Is Also a Single Point of Failure
On 18 November 2025, a faulty configuration file in Cloudflare's bot management system took down a large part of its network for several hours. On 5 December 2025, a change made to protect customers from the React vulnerability caused another outage that lasted about 25 minutes. During both incidents, sites behind Cloudflare showed error pages even though their own servers were running normally.
This is not a reason to avoid Cloudflare, but it is a reason to prepare. Make sure at least two people can log in to the Cloudflare account and the domain registrar, both with two-factor authentication. Write down how to switch the main records to DNS only in an emergency. That only works if the origin can take direct traffic and has a certificate that browsers trust, which is one reason to use Let's Encrypt on the origin rather than only an Origin CA certificate. And monitor the site from outside Cloudflare, so you know whether a failure is yours or theirs.
Data is the other consideration. Cloudflare decrypts HTTPS traffic in order to inspect and cache it, so it sees everything that passes through, including form submissions. For applications that process personal data under the Personal Data Protection Law, or that are supervised by OJK, list Cloudflare as a data processor in your documentation and check its data processing terms. Enterprise customers can add options to control where traffic is inspected and where logs are stored.
Alternatives to Cloudflare's WAF
| Option | Fits when | Cost notes |
|---|---|---|
| AWS WAF | The application already runs on AWS behind CloudFront or an Application Load Balancer, and rules should live in Terraform | $5 per web ACL and $1 per rule each month, plus $0.60 per million requests. Bot Control costs extra |
| Google Cloud Armor | The application runs on Google Cloud behind its load balancer | Charged per policy, per rule, and per request |
| Bunny Shield | You already use Bunny CDN and want a simpler WAF in the same dashboard | Priced per pull zone, check the current plans |
| Akamai, Imperva, F5 | Large companies and banks that want a managed service with a security operations team behind it | Annual enterprise contracts |
| OWASP CRS with ModSecurity or Coraza on your own server | Traffic must not pass through a third party, and the team has time to tune rules | The software is free, but tuning false positives takes real engineering time |
A self-hosted WAF filters requests well, but it cannot stop a large DDoS attack, because the traffic has already filled your server's bandwidth before the WAF sees it. ModSecurity is now maintained as an OWASP project after Trustwave ended its support in July 2024, and Coraza is a newer engine written in Go that runs the same OWASP Core Rule Set. For most business websites in Indonesia, Cloudflare in front plus a well-maintained application is the most practical combination.
Our managed services team sets up and reviews Cloudflare configurations as part of server and application maintenance, including origin lockdown, WAF tuning, and monitoring. If you are not sure whether your current setup is complete, a review usually takes less than a day.
Key takeaways
- Cloudflare only protects records set to Proxied, and only if the origin server cannot be reached directly. Lock the origin to Cloudflare's IP ranges or use Cloudflare Tunnel.
- Use SSL/TLS Full (strict) with a valid certificate on the origin. Flexible SSL leaves traffic to the server unencrypted.
- The free plan includes unmetered DDoS protection, the Free Managed Ruleset, five custom rules, and one rate limiting rule. Sites with logins or payments usually benefit from Pro.
- A WAF gives time to patch known vulnerabilities, but it does not catch business logic flaws such as one user reading another user's data.
- Check Security Events regularly, test webhooks and mobile apps after enabling bot protection, and prepare a plan for the day Cloudflare itself has an outage.


