Proof of Concept (PoC)

Proof of Concept (PoC) is the smallest demonstration that proves a vulnerability is real and reachable. A PoC proves the bug exists; an exploit weaponizes it for impact. The two differ in intent: a PoC does the least it can to be convincing, an exploit does the most it can to be useful to an attacker.

PoC vs Exploit

# PoC: proves arbitrary file read is reachable, and stops there
curl "http://target/download?file=../../../etc/passwd"
# Returning the contents of /etc/passwd is enough to prove the bug

# Exploit: weaponizes the same primitive
# read app secrets, pivot to the DB, drop a webshell, persist
# -- none of which the PoC needs to do to demonstrate the flaw

What Makes a Good PoC

• Minimal: one request or one payload, no incidental steps. If the bug reproduces with less, cut it down
• Deterministic: reproduces every run, not one in ten. Avoid timing races and environment-specific luck
• Safe by default: reads a marker, not data; pops a benign alert(), not a keylogger; touches nothing destructive
• Clearly scoped: shows exactly which input reaches which sink, so the reader sees the cause, not just an effect

Non-Destructive Markers

# XSS: prove script execution with a harmless marker
<script>alert(document.domain)</script>

# SQLi: prove injection by returning a known value, not by dumping tables
?id=1' UNION SELECT version(),user()--

Out-of-Band Verification

# Blind bugs have no visible response, so prove reachability with a callback
# SSRF: ?url=http://attacker-collab/ssrf-confirmed  -> DNS/HTTP hit received
# Blind XXE: external DTD fetch lands on your listener

An out-of-band hit is proof the input reached the sink even when the page shows nothing.

Disclosure

When reporting, keep the PoC at proof level and withhold the weaponized exploit until a patch is available.

See Also

• Exploit Payload
• Exploit Chain
• CVE