To confirm a DAST finding, replay the exact request the scanner sent, read the raw response, then change one variable at a time to see whether the behaviour holds. If you can reproduce it by hand and explain the cause, it is real. If not, treat it as unconfirmed.
Start from what the scanner gives you
A DAST alert should include the URL, the HTTP method, the parameter, the payload and the evidence, which is the part of the response that made the scanner suspicious. If your report lacks any of those, fix the report settings first. A finding without a request and a response cannot be checked.
The ZAP project's advice on false positives is blunt and applies to any scanner: make sure you understand the potential vulnerability being reported and test it manually before concluding it is not real. The reverse is just as true. Test it before concluding it is real.
Five steps
- Replay. Send the same request with a command line client or a proxy. Use a test account in a non production environment where possible.
- Read the response, not the status code. Many apps return 200 for an error page. Check whether the payload actually executed or was merely echoed back inside an encoded or inert context.
- Vary one thing. Remove the payload and compare. Change the payload to a harmless marker. If the behaviour changes with your payload and not without, the input matters.
- Check the effect. For injection, look for a changed result, a delay or an error that points at the backend. For cross site scripting, check whether the script runs in a browser, not just whether the string appears.
- Find the code. Trace the parameter to the handler. Knowing which line is at fault is what makes the ticket actionable, and it often settles the question.
Signs of a likely false alarm
| Observation | What it suggests |
|---|---|
| Payload is reflected but HTML encoded | Output encoding is working |
| Error page is identical with and without payload | Scanner matched generic error text |
| Finding appears only on a static asset | Rule fired on a header or file type, not on logic |
| Alert disappears on retry | Timing or rate limit artefact |
| Same alert on every URL | Likely a site wide header or banner rule |
What to put in the ticket
Include the request, the response excerpt, your reproduction steps, the affected code location and a proposed severity. A ticket written this way can be fixed without a meeting.
If you cannot confirm it after reasonable effort, do not close it silently. Mark it unconfirmed, note what you tried, and set a review date so the question is not forgotten. For a wider view of DAST triage, see why DAST reports false alarms.
Try it yourself
Open the demo and look at how a scan result lists the request, the evidence and the affected URL for each finding.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers reachability analysis to help judge whether a finding matters in context. 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 it safe to replay scanner requests against production?
Only with care. Active payloads can create records or trigger alerts. Prefer a staging copy and an account made for testing.
What if I cannot reproduce it?
Mark it unconfirmed with notes and a review date. Do not delete the alert, because intermittent bugs are real.
Sources
Last reviewed: 19 October 2026.
