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

I don’t understand the issue with the unit test - the rule is correct, and real-world tests work fine here.

Is there a problem with the regular expressions in the definition of the argument types targeted by the rule?

@touchweb-vincent The Unit tests aren't failing, it's the linter please see this

Normally we don't accept exceptions for specific applications within CRS itself, but we do accept tweaks to rules that reduce their overall false positives. Typically this would be in a plugin specifically for backoffice.

I don't think there's much we can do for this rule to reduce false positives simply due to the fact it's meant to block on multiple special characters which are very typical of injection attacks. This is painful for end users but it's also painful for attackers to bypass, it is placed at PL-3 for a reason after all.

I don’t understand why the linter is failing - if someone could help me with this, it would be appreciated.

@touchweb-vincent, could you pick up #4310 or rebase your branch? That will solve the seclang_parsing issue.

(You can use the [Update branch] button on this page.)

Hello @airween

Done, thanks you !

@EsadCetiner Not sure modsec like this form : /^\w+(?:[[\w-]*?]){2,3}$/ in an arg exclusion.

I reverted the change; ModSecurity definitely doesn’t seem to like curly brace here.