Home / Knowledge hub / Evidence of exploitation
Knowledge hub
Evidence of exploitation
The request, response and screenshot showing a flaw was truly used.
What it means
Evidence of exploitation is the material that shows a weakness was used, not just suspected. For a web application it normally means the exact request that was sent, the response that came back, and a screenshot or output that lets a person see the result. For code-assisted testing it can include the line of code behind it.
Good evidence can be replayed. Another engineer should be able to take the request, send it to a test copy and see the same thing. If the proof cannot be reproduced or understood by someone else, it is a claim, not evidence.
Why it matters
Evidence ends arguments. Without it, a finding passes through a developer who doubts it, a manager who cannot judge it and an auditor who cannot verify it. With it, the question moves from whether the flaw exists to when it will be fixed. That saves days on every disputed ticket.
It also protects both sides. For the tester, it shows the work was done within scope. For you, it is a record to hand an auditor or customer. It supports the claim made in an attestation letter and is the base of any exploited finding.
How it shows up
A solid piece of evidence includes the endpoint and method, the headers and body that matter, the response status and the part of the response that shows the problem. Session tokens and personal data should be redacted before the report is shared widely, but the structure must stay readable.
Weak evidence is easy to spot. It is a scanner log line, a version number, a generic description copied from an advisory, or a screenshot with no context. Ask for the request and the result, ask what account was used, and keep the evidence with the ticket until the fix is checked.
Questions people ask
Evidence of exploitation, answered
What counts as evidence of exploitation?
The request that was sent, the response received, and a screenshot or output showing the result. In white-box testing the file and line of code add to it.
It must be specific to your application, not generic.
Is a screenshot enough?
Rarely on its own. A screenshot shows an outcome but not how to repeat it. Pair it with the exact request and response.
The screenshot helps a non-technical reader see the impact.
Should evidence include real customer data?
No. Use test accounts and test data where possible, and redact anything real before sharing the report.
The structure should still show what was reachable. Never paste live customer records into a ticket where many people can read them.
How long should evidence be kept?
At least until the finding is verified fixed, and longer if audits or contracts require it.
Keep it with the ticket so it is not lost between tools. Retain it with the retest result, so one record tells the whole story from finding to fix.
How do I judge a vendor's evidence?
Check that you could replay it. Look for the actual request, the account used and the observed result.
Vague descriptions and copied advisory text suggest the flaw was never shown.
Sources
Where this comes from
Related
Terms that sit next to this one
Exploited finding
A finding confirmed by actually using it, not one that only looks likely.
Reproduction steps
The exact steps another person can follow to see a vulnerability for themselves.
Proof of exploit
Evidence that a flaw can be used to cause real impact, not just that it exists.
Security finding
One confirmed weakness in a report, with the evidence to show it is real.
Penetration test report
The document that lists what was found, how, how bad it is and how to fix it.
Can someone else replay it?
Every finding we report carries the request, the response, a screenshot where a person can see it, and the line of code in white-box mode. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.