This article provides tips and best practices on configuring the Cloudflare WAF.
By default, our WAF is configured to be compatible with almost all websites and web applications out of the box. This means that when you enable our WAF, the default settings will typically always work well for your website. However, as it is impossible to achieve 100% compatibility with the entire web, sometimes you may encounter issues like false positives. A false positive is when something is evaluated as true/positive when it's actually a negative, i.e. the diagnosis was wrong. In the context of our WAF this means a request getting blocked because it was mistakenly evaluated as malicious.
To deal with false positives and make sure they're avoided in the future, you need to know how to spot them, and how to correct them. To spot them, you would need to review the logs of requests that got blocked (more info below) and then evaluate whether it makes sense that these requests were blocked within the context of the expected and normal traffic of your website. To give an extreme example, if somebody was trying to POST PHP code to your website this would under normal circumstances be considered malicious or at least suspicious. If, however, your website is about learning how to code and requires code submissions from users, then PHP being POSTed may be entirely expected. In conclusion, whether a request should actually get blocked is subjective and unique to your website.
The rest of the guide explains how our WAF works in general, how to find specific information for blocked requests in your Cloudflare traffic logs, and finally how to adjust your WAF settings for individual rules and rulesets.
First, we'll describe the overall structure of our WAF. It contains 3 packages: Cloudflare Rulesets, OWASP rulesets, and Custom WAF Rules.
Cloudflare Rulesets Package:
Cloudflare Rulesets contains rulesets written and curated by Cloudflare engineers. Clicking on Rule Details will reveal the rulesets that this package consists of. You will find 10 rulesets called Drupal, Flash, Joomla, Magento, Miscellaneous, PHP, Plone, Specials, WHMCS, and Wordpress.
Specials contains a number of rules that we have found to be compatible with and appropriate for virtually all applications and websites on the internet. This ruleset is the core of the security that our WAF offers, with rules that target common attacks like SQLi, XSS, LFI, etc. Based on that, we recommend that you always leave Specials enabled.
Other than Specials, you should only enable the rulesets that correspond to your technology stack, i.e. if you use Wordpress but none of the other technologies then you should only enable the Specials and Wordpress rulesets. Enabling rulesets that are not relevant to your tech stack will likely cause issues.
By clicking on any of the specific Rulesets, you will be able to see further details about each of the rules that ruleset consists of.
You can set rules in the Cloudflare Rulesets Package to "Disable", "Simulate", "Challenge", or "Block".
You will note that you can change the behavior of specific rules within a ruleset. For example, if you notice one specific rule causing you false positives, instead of disabling the entire ruleset and thus lowering the level of the protection you receive, you should only disable the specific rule causing the issue in question.
As an aside, you can see in the screenshot above that the names of the rules don't reveal exactly how they work - they are mostly a general summary of their function. This is on purpose: for security purposes we don't reveal the code (or other exact information) we use to filter traffic. If this knowledge were easily accessible, it would allow malicious actors to reverse engineer it and bypass our defences.
OWASP Rulesets Package:
The OWASP Rulesets Package contains a number of rules from the OWASP project. These rules are not written or curated by Cloudflare engineers, and are provided as is. OWASP is an industry standard and provides a good security baseline. This package similarly consists of rulesets, each of which in turn consists of rules.
You will notice two main differences here:
a) OWASP allows you to set a "Sensitivity", whereas the Cloudflare Ruleset doesn't.
b) OWASP rules can only be turned "On" or "Off", whereas Cloudflare Rulesets rules can be set to "Disable", "Simulate", "Challenge", or "Block".
These are explained by a fundamental difference between how the Cloudflare Ruleset works vs the OWASP Ruleset. The Cloudflare Ruleset rules will either trigger or not trigger for a given request. If a request triggers any one of the rules, the action assigned to that rule ("Simulate", "Challenge", or "Block") will take place. OWASP, on the other hand, assigns a "severity" (like a threat level) to each request, based on how many OWASP rules get triggered. Some of those have a high severity score, and some have a lower one. After the request is evaluated, the final score gets compared to the sensitivity threshold you've selected, and if it exceeds it, the request gets blocked.
Generally we recommend setting OWASP sensitivity to "Low". Depending on how your web application or website works, there may be compatibility issues with OWASP, especially in the "High" sensitivity. We also suggest you test the "High" sensitivity: you can then check your logs on Cloudflare and see what gets blocked. Based on that and with previous knowledge of what your traffic looks like, you can decide if it's normal for that traffic to get blocked or if this is a false positive. Should you see too many false positives you should try "Low" sensitivity. If you are still seeing some false positives from OWASP, we recommend digging into the logs some more to find out which OWASP rules are causing these false positives, and then disable these rules specifically.
You can disable or enable rules within the OWASP Rulesets Package.
If, however, the "Low" sensitivity still causes too many false positives, then as a last resort we would recommend you disable OWASP completely.
Custom WAF Rules:
Custom WAF Rules, available on the Business and Enterprise plans, are rules that the Cloudflare WAF team writes specifically for a customer, based on that customer's unique requirements and/or their website's traffic patterns. This means that you can ask us to block virtually any combination of characteristics of a request. For example, we can make a rule that blocks a request if the URL contains the word "hello", and the User-Agent contains the word "world", and only if that request's Referer doesn't contain "example.com". The possibilities are endless. For Custom rules, we will either create a rule as per your requirements, or in some cases we will review traffic patterns using logs either on our end or from your servers, and come up with the appropriate rules that would protect you from any undesired traffic.
Reviewing WAF logs:
Reviewing WAF logs can give you unique insight into your traffic and any potential malicious activity against your website. It can also enable you to optimize your WAF configuration, which is exactly what we want to do here. You will find your logs in the "Traffic" tab on your Cloudflare dashboard under "Firewall Events".
"Firewall Events" shows you detailed information about requests blocked by the WAF.
In this example you see one blocked request. You can see that the "Action Taken" is "Block", and not "Challenge" or "Simulate" ("Block" being a hard block, "Challenge" being a CAPTCHA page that humans can bypass, and "Simulate" being a request that is allowed through normally, but is nevertheless logged). The Rule ID tells you what blocked this request; in this case the Rule ID is the OWASP Ruleset (all requests blocked by OWASP show this ID). Clicking into "Details" you can see some more information, for example the request URI.
The "Details" panel of a Firewall Event gives you detailed information about the blocked request.
At this point you should be able to decide: does this traffic look normal for my website, or did it rightfully get blocked? More importantly, you can click on "Show List" for "Rule(s) Triggered", which will reveal a detailed list of OWASP rules that were triggered here.
Detailed list of all the OWASP rules that triggered for this request. Each of these rules increased the threat level of the request based on their severity. The final threat level exceeded the sensitivity threshold for OWASP, and thus the request was blocked.
You can clearly see every single OWASP rule that was triggered. To the right, you can see which OWASP Ruleset the rules in question belong to. With this knowledge, if you decided that this block is a false positive, you could go back to your WAF configuration, and disable a few of these individual OWASP rules until this request doesn't exceed your sensitivity threshold any longer.
Our WAF is configured to work effectively and without errors for almost all websites out of the box. The default settings for the Cloudflare and OWASP Rulesets will in most cases both protect you from a large number of possible attacks, and also not cause false positives. If you do see false positives or issues with your application or website, we definitely encourage you to not disable either of the WAF Packages, or the WAF in general. We have never encountered a website that was entirely incompatible with our WAF, and it's always worth the time and effort to tune your WAF configuration. If you still have issues with your WAF configuration after reading this guide, feel free to open a ticket with our support team.