📊 Quantitative test results for language: eng, year: 2023, size: 10K, paranoia level: 1:
🚀 Quantitative testing did not detect new false positives

@touchweb-vincent 920340 only adds a notice (2 points) so that rule alone is not enough for a request to be blocked (5 is required by default). I agree the rule is likely redundant, but if you want to remove it then you should modify 920340 to give a critical scoring (5 points) so the request can be blocked at PL-1.

@coreruleset/core-developers were there false positives with 920340 in the past? Personally I haven't seen a single false positive from these rules.

@touchweb-vincent 920340 only adds a notice (2 points) so that rule alone is not enough for a request to be blocked (5 is required by default). I agree the rule is likely redundant, but if you want to remove it then you should modify 920340 to give a critical scoring (5 points) so the request can be blocked at PL-1.

@coreruleset/core-developers were there false positives with 920340 in the past? Personally I haven't seen a single false positive from these rules.

Well seen - i edited the score.

Hum, i don't see why the score is invalid, there is others declarations with setvar:'tx.inbound_anomaly_score_pl1=+%{tx.critical_anomaly_score}' and i don't see unit which force value.

@touchweb-vincent You also need to update the severity action to CRITICAL

Thanks

Imo, 920341 doesn't have sense - but maybe there is a good reason this rule exists that i don't have in mind.

It does have sense. The logic is that, on PL1, it will only log a notice. From PL2, request is blocked.

Anyway, i agree that we should block it on PL1.

The reason we didn't block at PL1 right away is that we didn't want to block old / minority browsers. We can argue about it, but we don't have any evidence to support a change to blocking now, i.e., we don't know how many FPs we would start to cause with this change.

@coreruleset/core-developers were there false positives with 920340 in the past? Personally I haven't seen a single false positive from these rules.

I'm not aware of any, but since the score is 2, they might have gone unnoticed.

IMO, we could give it a try. If people start complaining we can revert. @fzipi @dune73 what do you think?

Hi @theseion,

Here, we haven’t seen any false positives in the past 3 years of hard blocking.

There was only one third-party provider that was blocked, and it was a true positive since their corrupted usage neutralized the XML processor.

@theseion

The reason we didn't block at PL1 right away is that we didn't want to block old / minority browsers. We can argue about it, but we don't have any evidence to support a change to blocking now, i.e., we don't know how many FPs we would start to cause with this change.

afaict no-one has complained about that rule for creating log spam, so it must not be a common issue. Considering what this rule is meant to block, I think it's definitely worth it to give it a try to block it at PL-1.

I've edited the comment.

Ping @fzipi

@theseion accepted but there is now an error i cannot solve : 8:10 syntax error: mapping values are not allowed here (syntax)

Thanks @touchweb-vincent!