Home / Knowledge hub / Proof of concept
Knowledge hub
Proof of concept
The smallest demonstration that a vulnerability is genuinely real.
What it means
A proof of concept is the smallest demonstration that a vulnerability is genuine. Not a description of what might be possible, but the request that was sent, what came back, and enough detail for somebody else to repeat it.
It stays deliberately small. The aim is to prove the flaw exists, not to cause damage. A good proof of concept for a data exposure shows one record that should not have been visible, rather than downloading the table.
Why it matters
Without one, every finding costs your team time before anybody can act. A developer reproduces it, a lead judges whether it is real, and the discussion stalls on whether the tool understood the application. Most of the cost of security findings goes here, in arguing about them.
With one, the conversation changes shape. The request is there, the response is there, it reproduces or it does not, and the question becomes when it gets fixed rather than whether it is real. Cyberlop findings ship with the request, the response, a screenshot and the line of code, and we publish a full example.
How it shows up
A usable proof of concept names the endpoint and method, the account and role it came from, the payload, the response that shows the impact, and any conditions it needed. The account matters more than people expect. The same request sent by an administrator and by an anonymous visitor are two different findings.
Handle it carefully as well. If the demonstration contains real customer data, it belongs in a ticket system with access control on it, not in a chat channel that gets forwarded onwards.
Questions people ask
Proof of concept, answered
What is the difference between a proof of concept and an exploit?
A proof of concept shows the flaw is real. An exploit turns it into impact, reliably and often at scale.
A tester usually stops at the first. Writing the second is more work and, in a customer's production system, a worse idea.
Is it legal to write one?
Against a system you own or have written permission to test, yes. Against somebody else's, authorisation is what separates research from an offence, and the wording differs by country.
Get the scope in writing before you start, and keep it.
How much should it prove?
Enough for a developer to accept it, and no more. One record, one action, one clear response.
Extracting an entire customer table to make the point converts a finding into an incident you now have to report.
Should a proof of concept be published?
Not while the flaw belongs to somebody else and no fix exists. Coordinated disclosure, which the CERT guide sets out in detail, exists to sequence that properly.
Inside your own company the calculation is different, and the risk is who else can read the ticket.
What makes one unusable for a developer?
A screenshot with no request. A payload without the account it came from. A description that says the endpoint may be vulnerable.
If an engineer has to rebuild the test before they can start fixing, the report has handed them your work.
Related
Terms that sit next to this one
Exploit
The specific sequence that turns a suspected weakness into a real one.
False positive
A reported issue that turns out not to be real.
Vulnerability
A weakness that somebody could use to cause harm.
Remediation
The actual work of fixing a finding: the change, the review, the release.
Penetration test
A time-boxed engagement where skilled people attack your systems by hand.
Would your developers believe it?
Every Cyberlop finding ships with the request, the response, a screenshot and the line of code that allowed it, so nothing needs reproducing first. See an example, then book a pilot.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.