Proof of Concept Development
Develop reliable, safe, and convincing proof-of-concept exploits that demonstrate vulnerability impact without causing damage to the target.
Tools
Machine-readable JSON available at:
https://reconatlas.pages.dev/api/checklists/poc-developmentTags
// 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, andidorwhoamifor command injection — neverrm,drop, orshutdown - Redact sensitive data: blur or redact real user PII in screenshots and logs
Script template
Every PoC script should include:
- A header comment explaining what it does
- Clearly marked variable placeholders
- Expected output described in comments
- Error handling for common failure modes
- A clean exit that leaves no artifacts on the target