feat: comment on threshold should be more alarming

[touchweb-vincent]

Hello,

Just to be consistent with this : https://github.com/coreruleset/coreruleset/pull/4330/files

[EsadCetiner]

Please do not resolve comments that you haven't properly addressed, if you don't understand my request or disagree with it please speak up instead of marking it as resolved.

Right now your changes are very wordy, and is even confusing in some places.

[EsadCetiner]

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

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.

[touchweb-vincent]

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.

[EsadCetiner]

@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.

[touchweb-vincent]

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.
We see this constantly in the field: companies genuinely think CRS is “too strict” or that auditors are “being paranoid”, simply because the most widely used WAF vendor diverges from CRS recommendations.

This is why I feel the documentation should explicitly point out when widely used platforms violate the CRS model.
Not to shame anyone - but to prevent misunderstandings and to protect users who rely on CRS in good faith.

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.

[S0obi]

I agree with @EsadCetiner, the documentation should remain neutral.

I think the first paragraph is enough and gives useful details.

[EsadCetiner]

How does this sound? This version is more generic, and only uses Cloudflare as an example

Suggested change

	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.
	Some WAF vendors (Such as Cloudflare) set the default anomaly score well above our defaults, this is not a proper implementation of CRS and you should expect bypasses.

[EsadCetiner]

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.

Suggested change

	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 -
	Increasing the anomaly score threshold will allow some attacks to bypass the CRS rules.

[touchweb-vincent]

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.

[EsadCetiner]

@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.

[touchweb-vincent]

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.

1. Saying “some attacks will bypass CRS” is not enough for most users

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.

2. We are not “overloading” the reader - we are preventing a misinterpretation

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.

3. The reference to LFI/RFI and data exfiltration is not noise - it is context

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.

4. I am not rejecting your review - I am disagreeing with one specific point, with justification

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.

[EsadCetiner]

Suggested change

	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 -
	Increasing the anomaly score threshold above the defaults (5 for requests, 4 for responses) will allow a substantial amount of attacks to bypass CRS and hamper the ability of critical rules to function correctly. The anomaly score threshold should only ever be increased temporarily during false positive tuning.

If you apply this suggestion, then we can also remove the second paragraph.

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

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"

[touchweb-vincent]

I’ve responded to all your points. I understood from another PR that you - or at least Max - preferred having discussions marked as resolved so you can keep track of progress. I can handle it differently with you if you prefer.

I’m now waiting for your feedback on my responses.

[EsadCetiner]

@touchweb-vincent

I’ve responded to all your points.

I've tagged you in the comments you haven't addressed, I'm still waiting on them.

you - or at least Max - preferred having discussions marked as resolved so you can keep track of progress.

Yes, but you only mark a discussion marked as resolved once you are finished with it. Meaning you applied the suggestion, if you disagree with a suggestion or don't understand it you don't mark it as resolved, you ask follow up questions or express your disagreement until an agreement is come to.

[touchweb-vincent]

I’ve given you detailed explanations about why I disagreed with some points, and the two change requests have been marked as unresolved. I’m now waiting for your feedback.

[EsadCetiner]

I’ve given you detailed explanations about why I disagreed with some points

I don't see where you gave such an explanation, all I see are my own comments

[touchweb-vincent]

[touchweb-vincent]

I don't understand why you don't see it.

[EsadCetiner]

@touchweb-vincent You haven't published your review, that's why it says "Pending" in orange above your message.

You need to publish your review, you can do that by clicking the files tab and "submit review" at the top right:

[touchweb-vincent]

I had never seen this GitHub behavior in the past 3 years! Thank you!

[EsadCetiner]

Thank you, I understand your changes much better now. How do these suggestions sound?

[EsadCetiner]

How does this sound? This version is more generic, and only uses Cloudflare as an example

Suggested change

	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.
	Some WAF vendors (Such as Cloudflare) set the default anomaly score well above our defaults, this is not a proper implementation of CRS and you should expect bypasses.

[EsadCetiner]

Suggested change

	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 -
	Increasing the anomaly score threshold above the defaults (5 for requests, 4 for responses) will allow a substantial amount of attacks to bypass CRS and hamper the ability of critical rules to function correctly. The anomaly score threshold should only ever be increased temporarily during false positive tuning.

If you apply this suggestion, then we can also remove the second paragraph.

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

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"