feat: comment on threshold should be more alarming #251
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -90,7 +90,11 @@ Most detected inbound threats carry an anomaly score of 5 (by default), while sm | |||||||
| Rule coverage should be taken into account when setting anomaly score thresholds. Different CRS rule categories feature different numbers of rules. SQL injection, for example, is covered by more than 50 rules. As a result, a real world SQLi attack can easily gain an anomaly score of 15, 20, or even more. On the other hand, a rare protocol attack might only be covered by a single, specific rule. If such an attack only causes the one specific rule to match then it will only gain an anomaly score of 5. If the inbound anomaly score threshold is set to anything higher than 5 then attacks like the one described will not be stopped. **As such, a CRS installation should aim for an inbound anomaly score threshold of 5.** | ||||||||
|
|
||||||||
| {{% notice warning %}} | ||||||||
| Increasing the anomaly score threshold will not only allow some attacks to bypass CRS; it will also disable a substantial portion of the most critical WAF protections. In particular, thresholds higher than 5 effectively neutralize many high-severity rules - including major LFI/RFI safeguards and several protections against severe data-exfiltration vulnerabilities - | ||||||||
|
|
||||||||
| The blocking threshold should NEVER be increased beyond the default (5 for for requests, 4 for responses), except temporarily during testing. | ||||||||
|
|
||||||||
| The fact that major providers - such as Cloudflare in 2025 - set a default blocking level of 60 and consider 25 a "high" value is a security nonsense. | ||||||||
|
Member
There was a problem hiding this comment. This is an unnecessary detail, we do not have to name and shame every single provider that does not implement CRS correctly. It should already be clear that you should never raise the anomaly score above 5. This is something that Cloudflare needs to fix, not us.
Suggested change
Author
There was a problem hiding this comment. Cloudflare holds an authority in AppSec that is extremely difficult to challenge with certain audiences unless it is explicitly acknowledged that they are among the companies that do not comply with CRS standards. If we do not state this explicitly, these practices will never change. Cloudflare is the largest WAF provider in the small-business market, and we need support in helping business owners understand that the level of protection they receive is insufficient because it violates CRS standards.
Member
There was a problem hiding this comment. @touchweb-vincent You haven't addressed any of the issues I brought up in this comment. Please communicate why you didn't apply this instead of just ignoring my review. I can't approve this PR if you keep on ignoring me.
Author
There was a problem hiding this comment. Thanks for the follow-up. I’m not ignoring your review - let me address your points directly and explain why I did not apply your suggestion. You wrote that: “We should not name and shame every provider who implements CRS incorrectly.” “It should already be clear that nobody should raise the anomaly score above 5.” “This is something Cloudflare needs to fix, not us.” I fully understand these positions. However, the reason I believe Cloudflare must be mentioned explicitly is that these points are not clear at all to a large portion of real-world users. In practice, Cloudflare’s default configuration shape the expectations of hundreds of thousands of organisations. When a large provider enforces a blocking threshold of 60 and labels 25 as “high”, users assume this is correct and safe - and they routinely disregard the CRS documentation because Cloudflare’s defaults contradict it. This creates a major gap between what CRS is designed to do and how people believe it works. This is why I feel the documentation should explicitly point out when widely used platforms violate the CRS model. If we don’t state this clearly, the situation simply won’t change, because users will continue to trust Cloudflare’s defaults more than the CRS documentation. I’m absolutely open to reworking the wording so that it stays neutral and non-judgmental - but I believe mentioning Cloudflare directly is necessary for users to understand the discrepancy and its security implications. Let’s find a formulation we can both agree on. There was a problem hiding this comment. I agree with @EsadCetiner, the documentation should remain neutral. I think the first paragraph is enough and gives useful details.
Member
There was a problem hiding this comment. How does this sound? This version is more generic, and only uses Cloudflare as an example
Suggested change
|
||||||||
| {{% /notice %}} | ||||||||
|
|
||||||||
| {{% notice info %}} | ||||||||
|
|
||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to make references to specific attacks, it's pretty clear that raising the anomaly score threshold will lead to false negatives and bypass. It should be left at that. Being overly verbose will cause confusion as you'll be overloading the reader with information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that the implications may be obvious to you, but for the hundreds of third parties on whom we’ve run our diagnostic tool, they are absolutely not. Most of them have no understanding at all of the consequences of modifying the anomaly score threshold before blocking.
The sentence you propose gives the impression that it’s not a major issue - as if only “some” rules would be bypassed - which is completely disconnected from what happens in real-world environments. It is the opposite of alarmist: it reads as if the impact is minor, when in practice, raising the threshold disables entire sections of critical protections, often without the user realizing it.
I genuinely do not understand why you don’t want to make explicit the severe consequences that such laxity can cause. Without that clarity, users will continue to underestimate the risk, and the problem will persist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@touchweb-vincent You haven't addressed any of the issues I brought up in this comment. Please communicate why you didn't apply this instead of just ignoring my review. I can't approve this PR if you keep on ignoring me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me clarify this explicitly, because I am absolutely not ignoring your review.
You raised two main concerns:
“We shouldn’t reference specific attacks.”
“Stating that raising the score leads to bypasses should be enough.”
Here is why I did not apply your suggestion, point by point.
While this may sound obvious to experienced CRS contributors, it is not obvious at all to the vast majority of organisations we work with.
In real-world environments, people interpret “some attacks” as a minor issue - something acceptable, or low-risk.
We constantly see users raising the threshold because they believe the impact is negligible.
This is exactly how they end up disabling large sections of the WAF without understanding it.
So my wording is not intended to be verbose; it is intended to be explicit where ambiguity leads to dangerous misconfigurations.
Your concern is that more detail might confuse readers.
But empirically, the lack of detail is already confusing and misleading users.
If readers underestimate the consequences, they will misconfigure CRS.
This is not theoretical - we see it happening regularly during audits.
Spelling out that raising the threshold disables major protection categories is the only way to prevent that misinterpretation.
The examples are not an exhaustive list of attacks.
They are examples of categories of rules that silently stop working above certain thresholds.
This gives readers enough context to understand why raising the threshold is dangerous, without overwhelming them.
It is a balance between clarity and safety.
I am addressing your feedback directly here:
I disagree that the shorter sentence is sufficient,
I agree that the text should not become a long lecture,
and I believe the current version conveys the risk accurately without overwhelming the reader.
I’m absolutely open to adjusting the wording for tone or clarity - but not to removing the essential information that prevents users from harming their security posture.
I’m not ignoring your review; I’m explaining why the proposed shorter wording would lead to misunderstandings and unsafe configurations in the field.
If you think we can rephrase the paragraph while keeping the essential level of clarity, I’m happy to work on a version we can both approve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you apply this suggestion, then we can also remove the second paragraph.
I used the word "some" here since many attacks do often score very highly with CRS (The average is about 20 anecdotally). How does "substantial" sound? it's more than "some"