A low-value ZAP alert recurs on one query parameter. How do you scope an alertFilter to just it?

## Start from the default, which is wide A ZAP alert filter needs only two things: a rule identifier and a new risk. Everything else — URL, parameter, attack, evidence, method — is optional, and an optional clause that is absent is skipped rather than compared. So the minimum filter is the broadest one possible: that rule, on every URL and every input the run touches. Scoping is not something you do to a filter, it is something you stop leaving out. ## Narrowing it, clause by clause 1. **Pick the right identifier.** `ruleId` is a string equality check tried against two values: the alert's scan-rule id and its `alertRef`, the finer identifier a rule uses when it can raise several distinct alert types. Using the alertRef means the rule's other findings stay loud. Using the bare id means they do not. The plan accepts either — it only rejects a blank or negative value — so this choice is entirely yours and nothing will flag it. 2. **Name the parameter.** `parameter:` with `parameterRegex` unset is an exact string comparison against the alert's parameter field. This is the clause that does the real work here: it stops the same rule on a different input from being quietened alongside the one you meant. 3. **Bound the URL, carefully.** With `urlRegex: true` the pattern is matched against the alert's whole URI end to end, query string included. A pattern written for the path alone will therefore match nothing at all on a URL that carries a query — the trailing `.*` is not optional. This is a common silent failure on this add-on, and it produces a filter that validates, loads and does nothing. 4. **Restrict the method** if the noise only appears on one verb. `methods:` is uppercased on both sides, so case in the plan is irrelevant, and an empty list means every method. 5. **Leave `attack` alone for a passive finding.** The attack clause holds the payload a rule sent, and passive rules send nothing, so a clause naming a payload can never match an alert a passive rule raised. Use `evidence` instead if you need another anchor. | clause | what leaving it out costs you | |---|---| | `ruleId` as the bare rule id | every other alert type that rule can raise | | `parameter` | the same rule on every other input | | `url` | the same finding on every page, including ones nobody has looked at | | `methods` | the same path on every verb | ## Verify before you commit The add-on exposes actions that apply the filters it holds to the alerts already recorded, and matching actions that do the same walk but only **count** the matches without touching anything. Point one of those at a session from a previous scan: - A count of zero means the filter matches nothing. Almost always the URL pattern, and almost always the missing `.*`. - A count much larger than the number of instances you meant to quieten means a clause is missing. - A count equal to the instances you expected is the only result that should let the filter into the plan. It costs one call, and nothing in the plan validates reach for you: the job checks that the rule id is present and not negative, that the risk name is one of the accepted five, and that each pattern compiles — and only for the clauses whose regex flag is true. ## Know what you have and have not changed A filter is not an exclusion. The request was still sent to the target, the rule still ran, the alert was still written to the alert table with its evidence. What changed is the alert's score, and — for `'False Positive'` — specifically its confidence rather than its risk. The finding is still there for anyone who reads the output. The rewrite is also not silent. Each time a filter fires, the add-on increments a statistic keyed on the alert's reference and the new risk value, so a run can report that filtering occurred rather than just producing a shorter list of findings. That counter is what turns "we quietened it" into something a later reader can see. ## Where the filter goes Last, put it above the jobs that raise alerts. Filters are applied as each alert is recorded, not swept over alerts that already exist, so a filter registered after the scan matches nothing — and reports success while doing so.