In ZAP's alertFilters add-on, how does a global alert filter differ from a context one?

## What an alert filter is ZAP's `alertFilters` add-on lets you restate the score of an alert a scan rule has already raised. A filter is a small record: a rule identifier, some optional clauses the alert must match (URL, parameter, attack, evidence, HTTP method), and a `newRisk` — what the alert should carry instead. Nothing is deleted and nothing is blocked. The request was sent, the rule ran, the alert was written to the alert table, and the filter edits that record afterwards. A filter can live in one of two places, and choosing the wrong one is a common way a filter either does nothing or does far more than you meant. ## The global collection A global filter is owned by `GlobalAlertFilterParam`, which is an ordinary options object — it is written into ZAP's configuration and read back when ZAP next starts. Consequences that matter in a pipeline: - It is tested against **every** alert the run produces, no matter which context the alert's URL belongs to, and it is tested even when no context has been defined at all. - It outlives the session. In a container that is thrown away each run this is invisible; on a long-lived desktop or a reused daemon it is exactly why a filter someone added months ago is still quietly rewriting today's findings. - In an automation plan, a filter entry with no `context:` key becomes a global one. That is the intended way to ask for it, not an omission the job complains about. - The job's `deleteGlobalAlerts` parameter, when set true, clears the **whole** global collection before the job adds anything — not just the filters this plan is about to write. ## The context collection A context filter is held by a per-context manager keyed on the context's id, and it is serialised into the context itself. So: - It is only reached when the alert's URL is inside that context. A URL outside it never sees the filter. - It travels with the context. Export the context and the filters go with it; import it somewhere else and they arrive. - It is **not** persisted the way a global one is. Start a fresh session without loading that context back and the filter is gone. - In a plan it is asked for by name: `context: <the name used in env.contexts>`. If the name does not resolve, the job reports an error for that entry rather than silently promoting it to global. ## Side by side | | global filter | context filter | |---|---|---| | stored in | the add-on's own options | the context | | tested against | every alert raised | only alerts whose URL is in that context | | survives a new session | yes | only if the context is loaded again | | how a plan asks for it | omit the `context:` key | `context:` naming a context | | internal marker | context id `-1` | that context's own id | | order of evaluation | first | after every global filter | ## Which one wins when both could match The add-on walks the global collection first and applies the first filter that matches, then stops — it does not go on to look at the context collections. Only if no global filter matched does it walk each context whose scope contains the alert's URL and apply the first match there. Two practical readings: 1. A broad global filter shadows a narrower context filter for the same alert. If you want per-context behaviour, do not also leave a catch-all global filter in place. 2. The walk stops at the first match, so stacking filters to step one finding down twice does not work. ## Choosing one in a pipeline 1. If the noise is a property of one application and you already have a context for it, use a context filter — it is documented next to the thing it applies to and cannot leak onto another target. 2. If the noise is a property of the scan rule itself and you genuinely want it everywhere, use a global filter, and say so in the plan rather than relying on a filter someone left in a saved session. 3. If you inherited a daemon whose findings look wrong, list the global filters before you look anywhere else: they are the ones that are still there from last time.