In an OWASP ZAP scan policy, how do you turn a single active scan rule off?

## The switch, and why there is only one An active scan rule is turned off by setting its **`AlertThreshold` to `OFF`**. That is the whole mechanism, and it is worth noticing what is *not* available: `AttackStrength` has no off position, so there is no second way to do this and no ambiguity about which dial you reach for. The enum's own documentation says it plainly — `OFF` "indicates that the scanner is disabled. A scanner is not used when set to `OFF`." ## `OFF` and `enabled` are one state, not two Every rule also carries a boolean `enabled`, and it is tempting to treat that as a separate switch. It is not. `AbstractPlugin` keeps the two in lockstep in **both** directions: 1. `setAlertThreshold(level)` writes the level and then immediately recomputes `enabled` from it, so writing `OFF` disables the rule as a side effect of the write. 2. `setEnabled(true)` on a rule whose current threshold is `OFF` **resets that threshold to `DEFAULT`**, because "enabled at threshold OFF" is not a state the object is allowed to hold. 3. `getAlertThreshold()` on a disabled rule returns `OFF` even if nothing ever wrote it there. The practical consequence of point 2 is that anything which enables a rule silently discards your `OFF`. That is not hypothetical — see the dependency behaviour below. ## The policy-wide forms | what you want | how the `.policy` file says it | how an `activeScan-policy` job says it | |---|---|---| | one rule off | that rule's `<level>OFF</level>` under `<plugins>` | `threshold: 'Off'` on that rule's entry under `rules` | | everything off by default | `<scanner><level>OFF</level>` | `defaultThreshold: 'Off'` | | an allow-list | `<locked>true</locked>`, and name the survivors | list the survivors under `rules` with a threshold | The **off-by-default plus allow-list** pattern is the one worth knowing, because it is how the shipped minimal API policy in the container image is built: a policy-wide `<level>OFF</level>` with strength left at Medium, then a `<plugins>` block that names a handful of rules and gives each an explicit `<level>MEDIUM</level>`. The order matters and the code gets it right: `ScanPolicy` loads the per-rule entries first and applies the policy default afterwards, and the default only disables rules that did *not* carry their own explicit level. `<locked>true</locked>` is the declarative version of the same idea. When a policy is locked, `PluginFactory` checks each installed rule for a matching entry in the file and, finding none, sets that rule's threshold to `OFF`. An unlocked policy leaves unmentioned rules at the policy default — which is why an unlocked policy with an empty `<plugins>` block runs *every installed rule* at that default, unless the default is itself `OFF`. ## The trap: a rule you turned off can come back on `PluginFactory.reset()` runs before a scan and makes two passes over the rule set. The **first pass** walks every rule that is still enabled and enables that rule's declared dependencies, explicitly calling `setEnabled(true)` on any dependency that is currently off. Combined with the state coupling above, the re-enable also resets that dependency's threshold from `OFF` back to `DEFAULT`. So turning a rule off is not final while some other enabled rule declares it as a dependency, and ZAP ships rules with real dependency chains. If you must be certain a rule does not run, turn off the rules that depend on it too, or use a locked policy whose allow-list omits the whole chain. The same method has the opposite behaviour for a dependency that cannot be satisfied: if a rule's dependencies are not all present, `PluginFactory` disables that rule and sets its threshold to `OFF` itself, logging that it did so. A rule can therefore end up `OFF` without anyone writing it. ## What not to reach for instead - **Lowering the strength** is not a disable. The rule still runs and still reports; it just tries fewer payloads. - **Filtering the finding afterwards** is a different subject with a different mechanism, and it does not stop the requests — the rule has already attacked the target by the time an alert exists. Turning the rule off is what prevents the traffic. - **Deleting the rule's add-on** works but is a blunt instrument: the same add-on usually carries rules you do want, and the effective rule set becomes a property of the image rather than of the policy you can read.