Read an injection finding as a claim plus evidence. Check which request and parameter were tested, what payload was sent, what changed in the response, and what context the input landed in. Then reproduce it yourself. If the evidence does not match the claim, treat it as a possible false positive.
The parts of a finding
Most scanner reports for injection include the same ingredients, though names vary. Learn to find each one.
| Part | What to look for | Question to ask |
|---|---|---|
| Location | URL, HTTP method, parameter name or header | Is this a real, reachable input? |
| Weakness type | A label, often with a CWE ID | Does the fix match this class? |
| Payload | The test value that was sent | Is it harmless? What was it meant to trigger? |
| Evidence | Response text, timing, callback or status change | Does it prove the claim? |
| Context | Where the input appeared: query, HTML body, attribute, script, command | Which fix applies here? |
| Confidence | How sure the tool is | Do I need to confirm by hand? |
Match the evidence to the type
The OWASP testing material gives the typical signals for each weakness, so you can check that the evidence fits.
- SQL injection: a database error message, a content difference between a true and false condition, a response delay, or an out-of-band call. A finding that claims SQL injection but shows only a generic server error is weak.
- Reflected XSS: the test marker returned with special characters not encoded, in an executable position. The guide stresses checking exactly which characters came back unencoded and the context they appear in.
- Command injection: command output in the response, a delay, or a name lookup that reached a server the tester controls.
- Stored XSS: the payload was submitted in one place and found raw in another. The report should name both locations.
If the evidence type does not fit the class, ask the team or vendor why the tool believes it.
Check for common false positives
- The marker appears in the response but sits inside a comment, a text area or a non-HTML content type, so it never runs.
- A timing delay came from a slow server, not from the payload. Check whether a control request without the payload was fast.
- A different response length came from a changing page element, such as a timestamp or token.
- An error message mentions a character but the database was never reached.
Our post on why DAST reports false positives covers the causes in more depth.
Reproduce it
- Copy the exact request, including cookies and headers, into a proxy or command line client against a test copy.
- Send a control version without the payload and note the response.
- Send the payload and compare: content, status, length, timing.
- Try a small variation. If a slight change breaks the behavior in a way consistent with the claim, that increases confidence.
- Find the code that builds the query, page or command. Confirm there is concatenation or missing encoding.
Decide the severity
Combine the technical finding with context: who can reach the input (anonymous or authenticated), what the vulnerable code can touch (a read only report table or the customer database), and what protections sit in front. The same weakness type can be very different in risk. For ranking, see OWASP risk rating methodology.
Write the ticket so it gets fixed
A good ticket has the endpoint and parameter, the weakness type and CWE, the evidence in one or two lines, a reproduction request, the suggested fix class (for example parameterize the query or encode output for the HTML context) and the retest steps. See how to retest an injection finding.
Try it yourself
Click through it at your own pace, or open it full screen. Open a finding and look at what detail is shown and what is missing.
Quick check
Is a high-confidence finding always real?
Not always. Confidence is the tool's estimate. Reproduce high-impact findings before escalating.
Who should reproduce a finding, the scanner owner or the developer?
Whoever can do it fastest. The key is that someone confirms it once and records the exact request.
Safeguard offers a free scan at gold.safeguard.sh/scan with findings shown alongside reachability context for dependencies.
Sources
Last reviewed: 19 October 2026.
