How do you retest an injection finding after a fix?

Retest an injection finding by replaying the exact original request against the fixed build, then trying variants of the payload, then checking nearby inputs that share the same code. Finish by adding an automated test so the flaw cannot return unnoticed. A single clean rerun is not proof.

Why one rerun is not enough

When a scanner reports an injection flaw, the evidence shows one payload that worked. A fix that blocks that payload may only block that string. The OWASP A05 guidance warns that escaping and filtering techniques involve parsing complex strings and are error-prone when the underlying system changes. If the fix is a filter on one character, a variant with a different encoding may pass.

The right fix keeps data separate from commands. See how to prevent injection flaws. Retesting checks that you actually did that.

Six steps

1. Reproduce first. Before changing code, confirm the finding in a test copy with the original request. Save the request and the response. If you cannot reproduce it, you cannot show a fix.
2. Fix the construction. Replace string building with parameterization, a safe API or an allow-list, depending on the type.
3. Replay the exact request. Run the saved request against the fixed build. The vulnerable behavior should be gone: no database error, no different response for true and false conditions, no delay, no callback.
4. Try variants. Change the encoding, add whitespace, use a different quote character, try the same payload in other parameters, headers and JSON fields. The OWASP command injection material shows how filters fall to URL encoding and other tricks, which is why variants matter.
5. Check siblings. Search the code for the same pattern. If one query was concatenated, others near it may be too. Check other endpoints that call the same helper.
6. Rescan and compare. Run the same scan profile used before, with the same login and scope. Confirm the finding is gone and no new related ones appeared.

What counts as evidence

Auditors and customers who ask for retest evidence usually want this pairing. Keep it with the ticket.

Write the regression test

Turn the payload into a unit or integration test that asserts safe behavior. For a query, the test passes a quote and an always-true condition and checks that no extra rows come back and no error is raised. For a template or output, pass markup characters and check that the output contains them as encoded text. Keep a small list of payloads, including ones that previously worked, and run them in your normal pipeline. Our SQL injection lab shows a test of this kind.

Common retest mistakes

• Testing only in the browser, where client-side validation hides the server behavior. Send the request directly.
• Retesting with a different account or scan scope than the original.
• Closing the ticket because the scanner stopped reporting, when the cause was a scan that no longer reached the page. See why your scan misses pages.
• Fixing one parameter and not the others in the same form.
• Using a filter and calling it done.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a check can block a change before it merges, which is where a regression test pays off.

Quick check

Safeguard's policies and gates can enforce checks on pull requests, and a free scan is available at gold.safeguard.sh/scan.

Sources

• OWASP Top 10 2025: A05 Injection
• OWASP WSTG: Command Injection
• OWASP Query Parameterization Cheat Sheet

Last reviewed: 19 October 2026.