Ch 2: Sustaining Your Success

Source: Bug Bounty Bootcamp by Vickie Li (No Starch Press, 2021)

A report is how you get paid and build reputation. Bad writing = low payouts + duplicates marked invalid.

8-step report structure:

1. Title – one sentence: vuln type + location + impact. Example: “Stored XSS in /profile/bio allows attacker to steal session cookies”
2. Summary – 2-3 sentences. What is the bug, where is it, what can an attacker do?
3. Severity – CVSS score + label (Critical/High/Medium/Low). Justify your rating.
4. Steps to reproduce – numbered, exact, no assumptions. Another person must be able to reproduce with zero context.
5. Proof of concept – screenshots, HTTP requests/responses, video. Show it working.
6. Impact – explain real-world consequences. Who is affected? What data is exposed? What actions can be taken?
7. Mitigations – suggest a fix. Not required but earns goodwill.
8. Validate – test your own PoC before submitting. If it doesn't reproduce 100%, find out why first.

After submission you'll see one of these:

• Need more info – triage can't reproduce; provide more detail
• Informative – acknowledged but won't fix (low risk or by design); no payout
• Duplicate – someone reported it first; no payout
• Not applicable (N/A) – out of scope or not a valid vulnerability
• Triaged – accepted, being fixed; you'll get paid when resolved
• Resolved – fixed; payout issued

• Duplicates happen. Don't be discouraged. Look at public disclosures to learn the pattern.
• If marked N/A and you disagree, respond professionally with additional impact evidence.
• Never argue aggressively – you need the relationship with the program.

• Respond quickly when triage asks for clarification
• Be helpful: offer to verify the fix
• Keep communication professional even when payouts feel unfair
• Researchers with good reputations get private program invites

Common reasons beginners don't find bugs:

• Testing too shallow – only checking the obvious, not chaining small issues
• Only hunting well-known vulns – everyone tests the login page for SQLi; look where others don't
• Not understanding the application – you can't find logic bugs if you don't understand the intended workflow
• Giving up too fast – recon takes time; bug hunting requires patience
• Ignoring new features – new code = new bugs; watch changelogs and announcements

• Read public reports on HackerOne Hacktivity for the same target
• Look at the target's changelog/blog for new features
• Change your perspective: try a different user role, a different browser, mobile vs. desktop
• Take a break and come back with fresh eyes
• Switch targets temporarily and return later