One route breaks under the Core Rule Set at paranoia level 2: drop the level, raise the threshold, or exclude the rule - which gives an attacker least?

## Frame it as blast radius, not as difficulty Every one of the three options makes the control weaker somewhere. The engineering question is not which is easiest but which square of the estate you are spending, and the answer is a strict ordering: | Option | What loses protection | | --- | --- | | Drop the tier's paranoia level | Every rule at that level, on every route, for every field | | Raise the shared anomaly threshold | Every route, by the number of points you added | | Remove the rule globally by ID | That rule, on every route | | Exclude the rule for one path | That rule, on one path, on all its fields | | Exclude the rule for one path and one parameter | That rule, on one path, on one field | The list is also, read downward, the order of preference. A single broken checkout field justifies the last row and nothing above it. ## Step zero: is it actually a false positive? Before writing anything, establish that the refused requests are legitimate. Sometimes they are not: a route can be sending something genuinely alarming - a client library packing raw input into a field, a debugging parameter that was never meant to reach production, a partner integration posting a payload nobody reviewed. An exclusion written over a real finding is worse than a refusal, because it converts a loud problem into a silent one and it is very unlikely to be revisited. Pull a sample of the refused requests, look at what actually tripped the rule, and get the route owner to say the traffic is theirs and expected. ## Why a global rule removal is worse than it looks The tempting quick fix is to remove the rule by ID for the whole tier. It feels surgical because it is one rule. It is not surgical, because a shared ingress tier fronts dozens of teams: you have removed a piece of evidence from every route in the estate to fix one field on one of them. Under anomaly scoring the loss compounds - that rule was contributing points to totals on routes you never looked at, and some of those totals were the ones crossing the threshold. The engine supports scoping instead. Exclusions can be applied at configuration time - removing a rule, or better, removing one target from a rule, so the rule still evaluates every other field - and they can be applied conditionally at runtime, so the exclusion only takes effect for requests matching a particular path. Directives such as `SecRuleRemoveById` and `SecRuleUpdateTargetById`, and the runtime `ctl:ruleRemoveTargetById` action inside a rule conditioned on the request path, are the difference between removing a rule from the estate and removing one field from one rule on one route. Use the narrowest form that fixes the flow. ## Why raising the threshold is the dangerous option It is quick, it fixes the symptom immediately, and it leaves the configuration looking fully deployed - every rule still present, every level unchanged. What it actually did was widen the band of requests that are served, on every route sharing the setting, and hand an attacker who has measured your threshold exactly that much more room to keep each request beneath. Nothing about the change announces itself later. When you inherit a tier with a threshold of 20 and nobody remembers why, this is how it got there: three route owners in a hurry, on three separate afternoons. ## The fourth option a shared tier gives you Paranoia is not required to be a single number for the whole estate. The Core Rule Set's configuration variables can be set per route, so the honest answer on a shared tier is often: leave the fleet at PL2 and put this one route at PL1 while its owner fixes the field. That is wider than a targeted exclusion - the whole route drops a level - but it is enormously narrower than dropping the fleet, and it has the useful property of being obviously temporary and obviously attached to one team. ## Measure before and after Whichever instrument you choose, do the change in a non-enforcing mode first and count what it would have served, then compare after enforcing. The question you must be able to answer afterwards is not 'is checkout working again' but 'what is now served on this route that was refused yesterday, and does anyone object to that list'. If you cannot produce that list, you did not scope the change - you just stopped the complaints. ## What you say to the route owner The exclusion is a loan against their route, not a resolution. The rule fired because the field carries input the generic rule set cannot distinguish from an attack, and the durable fix lives in how the application handles that input. That conversation belongs to them, but the shape of the exclusion - one rule, one path, one parameter - is what keeps the loan small enough to be worth making.