Tune the scan rule first. If no setting fits, add an alert filter scoped to one rule and one URL or parameter pattern, with a written reason and an owner, and review it on a schedule. Broad filters are how real vulnerabilities end up hidden.
What alert filters are
Some DAST tools let you override how an alert is treated after it is raised. In ZAP, the Alert Filters add-on can change an alert's risk level, including setting it to False Positive, using criteria such as the rule, a URL, a regular expression or a parameter. Context filters apply within one scan context and travel with that context. Global filters apply to every alert and persist across sessions.
ZAP's own FAQ gives the order of preference: understand and manually test the alert first, then use the rule's thresholds and configuration options, and only if a rule has no suitable threshold, use alert filters to mark matching alerts. It also notes that reports exclude false positives by default.
A safe filter, step by step
- Confirm the alert is false. See how to confirm a DAST finding.
- Try the rule's own settings. A threshold change is narrower and easier to understand than a filter.
- Scope tightly. One rule ID, one URL pattern, and a parameter if possible. Avoid patterns like "everything".
- Prefer context over global. A context filter cannot silence the same rule on an unrelated application.
- Write the reason in the filter file or the commit message that adds it.
- Store it in version control so changes are reviewed like code.
- Add a review date and check it on the same cycle as other suppressions.
Safe and unsafe examples
| Filter | Verdict |
|---|---|
| One rule, on the health check URL only | Reasonable |
| One rule, on a documented third party widget path | Reasonable, with a note |
| One rule, all URLs, because the team is tired of it | Unsafe, tune the rule instead |
| Several rules, all URLs, set to false positive | Unsafe, you have disabled the scanner |
| A filter nobody remembers adding | Delete it and see what returns |
Measure what filters do
Count filters, count alerts they hide, and watch whether the hidden count grows faster than the code. The ZAP team itself cautions that people may use filters simply to hide alerts they do not care about, so a false positive count built from filters is not proof that the alerts were wrong. Apply the same scepticism to your own numbers.
Try it yourself
Open the demo and note how a finding is described by rule, URL and evidence, the same fields a filter matches on.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers policies and gates that keep rules explicit and reviewable. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Is a global filter ever acceptable?
Rarely. It is reasonable for a rule that is irrelevant to your whole estate, with an owner and review date. Otherwise prefer a context scoped filter.
Do filters change what the scanner tests?
No. They change how results are shown. To stop a rule running, disable it in the scan policy, which also saves scan time.
Sources
Last reviewed: 19 October 2026.
