PoC Quality: Reliable, Minimal, and No-Side-Effects Proofs

Cybersecurity

A proof of concept that deletes data, spams users, or only works once on a Tuesday will get your report closed and your researcher reputation dented. The goal is reliable, minimal, reversible. Here is how to build PoCs that triagers love.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 5, 2023 · 8 min read

Three properties of a good PoC

• Reliable, runs on a fresh account and reproduces every time
• Minimal, the shortest path from access to impact
• Safe, no destructive, noisy, or irreversible side effects

Reliable means deterministic

If your PoC depends on a race condition, document the window and provide a script with a loop and a clear success indicator. If it depends on a specific user, create test accounts and use those. Triagers should not have to guess timing.

Minimal means cut everything

Strip cookies, headers, and parameters one by one until removing any of them breaks the bug. The result is the smallest payload that demonstrates impact. A three-line curl beats a Burp Suite export every time.

Safe means reversible

1. Use your own test accounts as both attacker and victim
2. For IDOR, read instead of delete or modify
3. For SSRF, hit a benign internal endpoint, not production databases
4. For XSS, alert document.domain, never exfiltrate real session cookies
5. For SQLi, use select 1 or version, never drop or update

What never to do in a PoC

• Touch other users' data without permission
• Send emails, SMS, or push notifications to real users
• Mine crypto, exfiltrate large data sets, or pivot to other services
• Run automated scanners against pages explicitly out of scope
• Persist a payload that other researchers will trip over

Recording PoCs

For UI bugs, a sixty-second screen recording with cursor visible is gold. For CLI bugs, asciinema gives copy-pasteable transcripts. Avoid edited videos that hide failed attempts, triagers want to see the real flow.

Cleaning up after yourself

If your PoC created files, accounts, or webhook listeners, remove them or list them in the report so the program can clean up. Leaving stored XSS payloads live on a public page is grounds for ban on most programs.

The PoC harness

For chained bugs, write a single script that runs every step end to end. Number the steps in code comments so a triager can map output back to the report. This is the difference between a medium and a critical.

A boring PoC that always works beats a clever PoC that works sometimes.

When the PoC is the report

For complex bugs, a well-commented script is worth a thousand words. Push it to a private gist and link it. Triagers can read code faster than prose, and engineers can copy your test directly into a regression suite.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.