How does the OWASP Core Rule Set's anomaly score decide a refusal, and what room does a raised threshold give an attacker?

## Scoring, not a trip wire Early rule sets were pass/fail per rule: one match, one refusal. That design makes every single rule a potential outage, so every rule must be written tightly, and tight rules are exactly what an attacker reshapes their payload around. The Core Rule Set's anomaly-scoring mode exists to break that coupling. The mechanism is arithmetic: 1. Every rule carries a severity. Severity maps to a score: **critical 5, error 4, warning 3, notice 2**. 2. When a rule matches, it adds its score to a running inbound anomaly total for that request. It does not, by itself, refuse anything. 3. At the end of the request phase, the total is compared to the **inbound anomaly score threshold**, which ships at **5**. 4. If the total reaches the threshold, the request is refused. Otherwise it is served, and the individual matches are recorded anyway. So the default is calibrated such that one critical match is decisive on its own, while a single warning is not, and two warnings (3 + 3 = 6) are. A moderately suspicious request can be served; a request that is suspicious in several independent ways is not. That is the point: a rule can now be a piece of evidence instead of a verdict, which is what makes loose, higher-paranoia rules deployable at all. ## What this means for a request that passed A served request tells you the total stayed under the threshold. It does not tell you nothing matched. This trips people up constantly, because it inverts the usual reading: the record of a passed request can still contain several rule matches, and those records are the only trace that anything unusual was tried. The direction of the claim matters - a refusal proves the score reached the threshold, not that an attack occurred; a pass proves the score did not, not that the request was benign. ## The attacker's move, which is the whole point of this leaf The threshold is a number, the rule set is public, and the response to crossing it is observable. That is everything an attacker needs to calibrate. They send a series of requests of graded suspiciousness against your endpoint and watch where the refusals begin. The boundary between served and refused localises your threshold within a point or two, and from then on the attack is an optimisation problem: deliver the payload while keeping each individual request's score beneath the number. The ways under are ordinary. Split the work across several requests so that no single one accumulates enough. Choose an encoding or a placement that trips only the lower-severity rules. Move the payload into a part of the request that the high-severity rules do not target on this route. None of these defeat the rule set's understanding of the attack; they defeat the arithmetic. This is why the threshold is not a free tuning knob. When a route owner's flow is being refused and the quickest fix is to raise the tier's threshold from 5 to 10, you have not solved a false positive - you have doubled the working room of every attacker against every route that shares that setting, and you have done it in a way that produces no alert and no visible change. ## Reading a score trace Given a record showing which rules matched and what each contributed, the questions worth asking are: what was the total, what was the threshold at the moment of the decision, which single match dominated the total, and would removing that one match have changed the verdict? That last question is the honest test of whether a proposed exclusion is narrow enough to be safe: if pulling one rule out of the arithmetic takes a request from refused to served, that rule was carrying the decision on that route, and you should know exactly what else it was carrying. ## Two settings, two different arguments Paranoia level and anomaly threshold are frequently conflated and they answer different questions. The level decides **which rules are allowed to speak**; the threshold decides **how much accumulated suspicion is required to act**. Lowering the level removes evidence sources fleet-wide. Raising the threshold keeps every source but demands more of them before acting. They fail differently too: a level that is too high produces loud, visible breakage that gets reported; a threshold that is too high produces silence, which is precisely what makes it the more dangerous of the two to reach for under pressure.