Proof of concept vs proof of exploit
The useful question is what the evidence demonstrates on the tested application. A proof of concept can be a working exploit; calling something a “proof of exploit” does not automatically make its evidence stronger.
Start with the evidence, not the label
In security work, a proof of concept (PoC) is a demonstration of a technique or vulnerability. It may run on a small test program, a reproduced environment, or the actual application under assessment. It is misleading to assume every PoC is merely theoretical.
At Sintropyc, exploit proof means recording the observable effect that supports a finding on an authorized target. That is an evidence standard for the report, rather than a universal naming rule. A short, reproducible PoC with the right observations can meet that standard.
Example: did an ID change really expose another account?
Consider a hypothetical staging app with two test users, A and B. A owns a private invoice with a distinctive test marker. B signs in with a separate session and requests A’s invoice identifier. If the response contains A’s private marker, the observation supports a cross-account read.
A changed ID and an HTTP 200 alone are insufficient. The invoice might be intentionally public, both sessions might belong to the same user, or the response might contain only an error wrapper. Record ownership, the two identities, expected permissions and the returned test marker. Read the IDOR guide for the authorization context.
What the finding should include
- The tested environment, relevant build and prerequisites.
- The identity and permissions used, with credentials removed.
- The minimum request sequence and the observed effect.
- A control observation that distinguishes the flaw from normal behavior.
- The demonstrated impact, unresolved questions and recommended correction.
Keep sensitive values out of the shared report. OWASP’s reporting guidance recommends enough detail to reproduce and remediate findings, with sensitive data masked.
Retest the boundary that failed
After the authorization fix, repeat B’s request for A’s invoice and confirm that the private marker is unavailable. Also confirm that A can still read their own invoice. A failing request is not sufficient if the entire invoice feature has stopped working.
A successful retest supports a bounded conclusion: this reproduction no longer crosses the tested boundary on this build. It does not prove that every related endpoint is secure. Sintropyc’s anonymized IDOR case study illustrates why suspected findings need controls and why reported impact should stay within the evidence.