Cloudflare WAF Setup
Custom rules written for your endpoints, tested in log mode against real traffic, then promoted to block with written documentation.
Explore this service →Cloudflare Security Guide
Cloudflare WAF Setup Guide for Business Websites
Turning on managed rules is not a WAF configuration. This is the process for building rules around your actual endpoints, testing them before they block anything, and keeping false positives close to zero.
- CEH Certified
- Top Rated Plus on Upwork
- 100% Job Success
- Handled directly, not outsourced
Before writing any rules
Map the application, then decide what to protect
Every bad WAF configuration starts the same way: rules copied from a checklist and applied to a site nobody looked at. The rules that matter are the ones written against your real paths, so the first task is an inventory.
Write down the login paths, the admin area, the API endpoints and what they accept, checkout and payment callbacks, search and any other expensive query, file upload paths, webhook receivers, and any third party integration that posts to your site. For each one, note the expected methods, roughly who should be calling it, and what abuse of it would cost you.
That last column decides priority. A rule protecting checkout is worth more than a rule protecting a marketing page, and it justifies more testing before it goes live.
Know your normal traffic first
Before adding anything, spend time in the analytics. Where does traffic come from, what does a normal request rate per visitor look like, which integrations call you from fixed addresses, and what does the daily peak look like. Rules written without this produce thresholds that either never fire or fire on your best customers.
Step one
Enable managed rules in log mode, not block mode
Cloudflare managed rulesets give broad coverage against common attack classes for very little effort, and they are the right starting point. What is not right is enabling them in block mode on a live site.
Deploy them in log mode and leave them there for at least a week, longer if your traffic is seasonal. Then review what they would have blocked. On most business sites the review turns up several rules firing on legitimate behaviour: rich text editors that look like script injection, file uploads that look like payload delivery, API clients sending JSON that trips a generic pattern.
Fix false positives with skips, not by disabling rulesets
When a rule fires on legitimate traffic, identify the specific rule ID and write an exception scoped to the path and condition where it is wrong. Disabling the entire ruleset because one rule is noisy is the most common way sites end up with no protection at all while believing they have plenty.
Only after the log review is clean should the ruleset move to block. Do it during working hours, with someone watching, not on a Friday evening.
Step two
Write custom rules for what is specific to you
Managed rules handle the generic. Custom rules handle your application, and this is where the actual value sits, because targeted attackers go after your specific endpoints rather than generic patterns.
The patterns worth implementing on most sites:
- Administrative paths restricted by source. If your team works from known locations or a VPN, restrict the admin area to those and challenge everything else. This alone eliminates most brute force pressure.
- Method restrictions. Endpoints that should only ever accept GET should reject POST at the edge.
- Known abuse paths challenged or blocked. On WordPress,
xmlrpc.phpis the classic example, since it is heavily abused for brute force amplification and most sites do not need it. - Country or ASN conditions where the business genuinely justifies them. Combine with other conditions rather than blocking whole countries outright, since that reliably blocks real customers and VPN users.
- User agent and header consistency checks to catch automation that does not bother to look like a browser.
Keep expressions readable
A rule nobody can read in six months will not be maintained, and unmaintained rules get disabled the first time they cause a support ticket. Prefer several clear rules over one clever expression, and write a short description on every one explaining what it is for.
Step three
Rate limiting is where most real protection comes from
Rate limiting is consistently the most underused control and frequently the most effective, because most automated abuse is defined by volume rather than payload. A WAF rule asks whether this request looks malicious. A rate limit asks whether this client is behaving like a person, which is a much harder question for an attacker to defeat.
The paths that need limits on almost every site: the login endpoint, password reset, registration, checkout and payment callbacks, search, and every API route. Each needs its own threshold, because a login attempt rate that is obviously hostile is a perfectly normal search rate.
Setting thresholds that work
Derive them from your own data rather than a blog post. Look at the ninety fifth percentile request rate per client for the path, then set the limit meaningfully above it. Start generous, watch what gets caught, and tighten. A limit set too aggressively on checkout costs more in a day than the attack it was blocking.
Choose the response deliberately too. A managed challenge is often better than a hard block on paths where a false positive is expensive, because a real user passes it and a script does not.
Step four
Protect the origin, or none of this matters
Every rule above assumes traffic arrives through Cloudflare. If your server IP is still reachable directly, an attacker who finds it bypasses the entire configuration in one request. This is the most common serious gap in otherwise well configured accounts.
Close it: configure the origin firewall to accept traffic only from Cloudflare IP ranges, use authenticated origin pulls so the origin can verify the request came from your account, and change the server IP if it has been exposed historically. Then check the leaks. Old DNS records, mail servers on the same host, SSL certificate transparency logs and error pages that print the server address all give it away.
Full strict SSL between edge and origin belongs here as well. Flexible mode leaves the connection between Cloudflare and your server unencrypted, which quietly undoes part of what you switched HTTPS on for.
Step five
Test like an attacker, then keep the configuration alive
A configuration that has never been tested is a hypothesis. After deployment, verify that each rule fires on the traffic it targets and does not fire on anything else. Walk the real user journeys yourself: register, log in, search, add to cart, check out, submit every form, upload a file, call each API endpoint with a valid client. Anything that breaks under a rule you wrote should be found by you, not reported by a customer.
The maintenance part nobody schedules
WAF configurations decay. New endpoints ship, integrations change, traffic patterns shift and thresholds that were right last quarter start catching real users. Review firing rules monthly, check for rules that have not fired in months and may no longer be needed, and re-check the configuration whenever the application changes materially.
Once the WAF is stable, the next layer is telling automation apart from customers, which is a different problem with different tools. That is covered in the bot protection guide.
Get this implemented
Cloudflare configuration services
If you would rather have this built, tested and documented for your site, these are the relevant engagements.
DDoS Protection
Layer 7 mitigation tuned to your traffic profile so attacks are absorbed without taking legitimate users offline.
Explore this service →Integration Fixes
For sites where Cloudflare is already on and breaking things: redirect loops, SSL errors, caching problems, blocked integrations.
Explore this service →Frequently asked questions
Cloudflare WAF questions
Do I need a paid Cloudflare plan for a useful WAF?
A meaningful amount is achievable on lower tiers using custom rules and rate limiting. Some capabilities, including the full managed rulesets and advanced bot management, require higher plans. Establish which of your specific requirements need a paid tier before upgrading, because many sites buy a plan for a feature they never configure.
Why is my WAF blocking legitimate users?
Almost always because managed rules were enabled in block mode without testing against real traffic. Form posts with rich text, file uploads, API clients and admin workflows trigger generic rules regularly. Move the offending ruleset to log mode, identify which rule ID is firing, and write a targeted skip for that path rather than disabling the whole set.
Should I use managed rules or custom rules?
Both, for different jobs. Managed rules give broad coverage against common attack classes with no effort. Custom rules cover what is specific to your application, which is where targeted attacks actually happen. Managed rules alone leave your specific endpoints unprotected, and custom rules alone leave you writing signatures for problems already solved.
Will a WAF slow my site down?
Rule evaluation happens at the edge and adds a negligible amount of time. In practice most sites get faster, because filtered traffic never reaches the origin and the server has more capacity for real requests.
Does the WAF protect my API?
Only if you configure it to. API endpoints have different traffic patterns from pages, and generic rules frequently break them by rejecting valid payloads. API paths need their own rules, authentication requirements and rate limits. That is covered in the API security service.
Can Cloudflare replace my WordPress security plugin?
It can replace the traffic filtering component, and generally does it better and with less origin load. It cannot replace file integrity monitoring, malware scanning or update management. Running full plugin firewalls and a properly tuned WAF at the same time usually means paying twice and debugging conflicts.
Keep reading
Related guides
Explore the Related Security Service
Use this guide alongside the relevant commercial service: security services, WordPress security, Cloudflare security, and click fraud prevention.
Direct help
Need this implemented on your website?
Talk directly with Xequent about WordPress security, Cloudflare protection or click-fraud controls.
Direct Expert Contact
Speak directly with Rana Shahwaiz Aslam
Xequent is operated by Rana Shahwaiz Aslam. The current professional profile shows 100% Job Success, Top Rated Plus, 37 jobs, and 851 hours on Upwork, with pricing scoped to the engagement rather than an open-ended hourly meter. Rana's profile title identifies him as CEH Certified and focused on managed Cloudflare security and cybersecurity.