Proof of Concept Requirements for Bug Bounty Reports

Not all programs require a PoC. Some want video, others want code. Learn exactly what format each major program expects before you submit.

Do You Need a PoC?

Short answer: Yes, for most high-paying programs. Check the specific program first.

Most programs on HackerOne and Bugcrowd require a PoC for any finding above low severity. Some accept a detailed technical description, but a reproducible PoC significantly increases triage speed and bounty approval.

Why programs require PoCs: A PoC proves the vulnerability is real, exploitable, and not a false positive. It lets the triager verify independently without needing to trust your description.

PoC Formats Accepted

1. Step-by-Step Instructions (Most Common)

A numbered list of exactly what a triager needs to do to reproduce the issue:

Example:
1. Log in to account X with credentials...
2. Navigate to /admin/users
3. Intercept the request in Burp Suite
4. Change user_id=1 to user_id=2
5. Forward the request
6. Observe that you can view another user's data

When to use: Any web vulnerability. This is the fastest format for triagers to verify.

2. Video Recording

A screen recording showing the exact steps and result.

When to use: Complex multi-step flows, race conditions, or UI-specific issues. Keep it under 2 minutes and include audio explaining what is happening.

3. Code Exploit

A script or code snippet that demonstrates the vulnerability:

Example: A Python script that uses the API to trigger the vulnerability, with clear output showing the successful exploitation.

When to use: API vulnerabilities, automation, or complex logic flaws. Always include comments explaining what the code does.

4. cURL / HTTP Request

A raw HTTP request that triggers the vulnerability (useful for API bugs):

curl -X POST https://target.com/api/users \
-H "Authorization: Bearer [token]" \
-d '{"admin": true}'

When to use: API endpoints, authentication bypasses, injection vulnerabilities.

5. Burp Suite Export / HTTP Archive (HAR)

Export the request/response pair directly from Burp Suite.

When to use: When the request is complex and you want to provide it in a format the triager can import directly.

Platform-Specific PoC Requirements

HackerOne

Required: PoC for high and critical findings. Medium and below can often go without, but including one speeds triage.
Format: Step-by-step instructions or video. HackerOne accepts markdown.
Scope: The PoC must work on the in-scope application, not a test environment you control.

Bugcrowd

Required: Most programs require reproducible steps for any finding.
Format: Detailed written steps or video. Bugcrowd's interface has a "Proof of Concept" field.
Tip: Include before/after screenshots showing the vulnerability.

Intigriti

Required: Program-specific. Check the "Requirements" section of each program.
Format: Flexible — video, steps, or code accepted.

Smaller / Private VDPs

Always check the program's submission guidelines first.
Most require at least a written, reproducible set of steps.

PoC Best Practices

Be Specific and Reproducible

❌ Bad: "The API leaks user data due to improper authentication checks."

✓ Good: "Call GET /api/user/12345 without a valid token and observe that the response includes the user's email and phone number."

Include Context

Explain what the vulnerability is and why it matters, not just how to trigger it.

Test Your PoC

Before submitting, follow your own steps. If they do not work, the triager will reject the report.

Keep It Focused

Do not include unrelated screenshots or steps. Every step should move toward the vulnerability.

Respect the Target's Data

If the PoC involves accessing another user's data, use test accounts you control or create on the target application, not real user accounts.

What If You Cannot Build a PoC?

Some vulnerabilities (race conditions, timing attacks, or issues on endpoints you cannot reach) are hard to reproduce in a PoC.

Explain why in your report. Give as much evidence as possible (logs, timeline, statistical analysis).
Provide partial PoC. Show the setup and what would trigger it, even if you cannot complete the full exploitation.
Ask the triager. Some programs accept detailed technical evidence instead. Escalate the report if needed.

Quick Checklist Before Submitting

□ I checked the program's PoC requirements (not all require one).
□ My PoC is reproducible from my written/video steps.
□ I tested the PoC at least once to confirm it works.
□ I did not include unrelated screenshots or steps.
□ My PoC focuses on the specific vulnerability, not the discovery process.
□ I used respectful, test-only accounts (not real user data).