Proof of Concept Development

Reporting MED v1.0.0 updated 2026-06-17

Develop reliable, safe, and convincing proof-of-concept exploits that demonstrate vulnerability impact without causing damage to the target.

Tools

curlPythonBurp Suitescreen recording tools

Tags

reportingproof-of-conceptexploit-developmentsafe-exploitationdocumentation

// checklist steps

poc-01

Create minimal reproduction script

Write the shortest possible script (curl one-liner or Python) that reproduces the vulnerability from a clean state.

# Curl one-liner PoC example
curl -sk -X POST https://target.com/api/vulnerable -H 'Content-Type: application/json' -d '{"payload":"<script>alert(document.domain)</script>"}' | grep '<script>'
# Python PoC example
python3 -c "import requests; r = requests.post('https://target.com/api/vulnerable', json={'payload': '<script>alert(1)</script>'}); print('Vulnerable!' if '<script>' in r.text else 'Not vulnerable')"

The PoC should work with a single copy-paste command. Avoid dependencies beyond standard libraries. Include expected output in comments.

poc-02

Ensure safe exploitation

Verify that your PoC does not modify data, delete records, access real user information, or cause denial of service on the target.

# Safe: read-only data access demonstration
curl -sk https://target.com/api/users/1 -H 'Authorization: Bearer <token>' | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'Access confirmed: user {d.get(\"id\",\"?\")}, email domain: {d.get(\"email\",\"?\").split(\"@\")[1] if \"@\" in d.get(\"email\",\"\") else \"?\"}')" 

Use read-only methods where possible. If the vulnerability requires a state change (e.g., CSRF), use your own test account as the victim. Never demonstrate impact on real user accounts.

poc-03

Create automated PoC with clear variable placeholders

Write a self-contained script with clearly marked placeholders (TARGET_URL, SESSION_TOKEN, USER_ID) that a triager can customise and run.

python3 -c "
TARGET = 'https://target.com'
TOKEN = '<your-session-token>'
USER_ID = '<victim-user-id>'
import requests
r = requests.get(f'{TARGET}/api/users/{USER_ID}', headers={'Authorization': f'Bearer {TOKEN}'})
print(f'Status: {r.status_code}')
print(f'Response: {r.text[:200]}')
"

Use ALL_CAPS for placeholders. Add a comment block at the top explaining what the script does, what it expects, and what output indicates success.

poc-04

Record video walkthrough with narration

Create a screen recording that shows the entire exploitation process from start to finish, with text or voice narration explaining each step.

Keep the video under 3 minutes. Start from a clean browser session. Show the network tab or Burp proxy to demonstrate what happens at the HTTP level. Highlight the moment where the vulnerability triggers.

poc-05

Document environment and prerequisites

List all prerequisites, tools, environment details, and accounts needed to reproduce the vulnerability.

# Document the test environment
echo 'Browser: Chrome 126.0 | OS: Ubuntu 24.04 | Burp Suite 2024.x | Python 3.12'

Include browser version, operating system, any extensions or proxy settings, and whether special network conditions are required. Some vulnerabilities are browser-specific or require particular TLS settings.

poc-06

Handle edge cases and failure modes

Document known limitations, race-condition timing requirements, and conditions under which the PoC may fail.

If the exploit has a success rate below 100%, document it (e.g., "Race condition succeeds in approximately 3 out of 10 attempts"). List conditions that prevent exploitation (e.g., "Requires victim to be logged in within the last 30 minutes").

Overview

A proof of concept transforms a theoretical vulnerability into a demonstrated security risk. The best PoCs are minimal, safe, and self-contained — a triager should be able to reproduce the finding by running a single command or script without installing custom tools.

PoC safety guidelines

  • Read-only first: demonstrate access without modification whenever possible
  • Use your own accounts: if the vulnerability requires a victim, use your test account
  • No destructive payloads: use alert(document.domain) for XSS, DNS callbacks for blind injection, and id or whoami for command injection — never rm, drop, or shutdown
  • Redact sensitive data: blur or redact real user PII in screenshots and logs

Script template

Every PoC script should include:

  1. A header comment explaining what it does
  2. Clearly marked variable placeholders
  3. Expected output described in comments
  4. Error handling for common failure modes
  5. A clean exit that leaves no artifacts on the target

// references

  1. https://docs.hackerone.com/hackers/quality-reports/
  2. https://portswigger.net/web-security
  3. https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
  4. https://owasp.org/www-project-web-security-testing-guide/
  5. https://github.com/projectdiscovery/nuclei
← All checklists JSON ↗