Bug Bounty Hunting · lesson 03
Writing reports that get paid
Impact-first titles, copy-pasteable PoCs, and how to handle triage replies calmly.
8 min read
A great bug with a poor report gets closed as informative or paid a fraction of its worth. The report *is* the product you’re selling.
The anatomy of a strong report
- Title, impact-first: “Reflected XSS on app.target.com leads to session theft”, not “XSS found”.
- Summary, 2–3 sentences: what, where, why it matters.
- Steps to reproduce, numbered, copy-pasteable, with exact requests.
- Proof of concept, the request/response that demonstrates it, not just a screenshot.
- Business impact, the realistic worst case, in the company’s terms.
- Severity, a CVSS vector you can defend.
tip
Demonstrate *impact*, not just presence. A reflected payload isn’t XSS until it executes; an exposed endpoint isn’t a bug until you show what it leaks.
Handling triage replies
You’ll get pushback, “duplicate”, “can’t reproduce”, “out of scope”, “lowering severity”. Respond like a professional:
- Acknowledge their position calmly.
- Give the single most decisive *new* piece of evidence.
- End with one specific ask.
- Never CVSS-spam, never threaten public disclosure, and give them a working day to respond.