Proposed changes

Hello,

As you know, many deployments do not follow OWASP CRS recommendations, namely blocking at a score of 5. As a result, it is common to encounter integrations where the blocking threshold is set much higher, often around 25 points.

We all know that some rules are particularly critical and have no false positives, or only extremely rare ones.

I therefore propose introducing a new score : danger_anomaly_score, which would increase the anomaly score by 25 points, in order to maximize the likelihood that these rules are still triggered even when the blocking threshold is set excessively high.

Some of you will probably reply that this is a dog chasing its own tail, and that questionable integrators will simply adapt by increasing the blocking threshold even further.

I agree with this point.

However, I believe that if this new score is used very sparingly, it can still help improve the security of projects relying on OWASP CRS. At the very least, it sends a clear signal that the rule captures inherently dangerous inputs, with no observed false positives or extremely rare legitimate use cases, which must be mitigated on a case-by-case basis.

For those who will reply that “all rules with a critical anomaly score” are “dangerous”, I also agree with you.

However, we all know that some of them are difficult - if not very difficult - to safely enable in production in certain contexts, particularly in e-commerce environments.

Here are a few examples of rules that could fall under this new score:

• 933100 https://github.com/coreruleset/coreruleset/blob/main/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf#L47
• 933110 https://github.com/coreruleset/coreruleset/blob/main/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf#L89
• 933140 https://github.com/coreruleset/coreruleset/blob/main/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf#L213
• 933170 https://github.com/coreruleset/coreruleset/blob/main/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf#L432
• 933200 https://github.com/coreruleset/coreruleset/blob/main/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf#L251

If you agree with this approach, I can work on a more exhaustive list based on our field experience and feedback.

What do you think ?

Thanks, for your time.

PR Checklist

• I have read the CONTRIBUTING doc
• I have added positive tests proving my fix/feature works as intended.
• I have added negative tests that prove my fix/feature considers common cases that might end in false positives
• In case you changed a regular expression, you are not adding a ReDOS for pcre. You can check this using regexploit
• My test use the comment field to write the expected behavior
• I have added documentation for the rule or change (when appropriate)

Further comments

For the reviewer

• Positive and negative tests were added
• Tests cover the intended fix/feature properly
• No usage of dangerous constructs like ctl:requestBodyAccess=Off were used in the rule
• In case a regular expression was changed, there is no ReDOS
• Documentation is clear for the rule/change