Going deep on a single bug bounty program

How it works

Step by step

1. 1Choose one public program with a wide scope: hundreds of subdomains, active engineering, a history of paying $500+ for medium-severity bugs. Read the last 90 days of resolved reports.
2. 2Read the program's scope page line-by-line. Note the out-of-scope list — most duplicate reports come from ignoring it.
3. 3Spend the first weekend on reconnaissance: subdomain enumeration (amass, subfinder), DNS history (SecurityTrails), and a full URL crawl (katana, gau). Save everything to a versioned repo.
4. 4Build a personal Notion or Obsidian wiki: one page per subdomain, tech stack, notable endpoints, past disclosures. This becomes your unfair advantage.
5. 5Subscribe to the program's changelog, engineering blog, status page and any public GitHub org. Every release is a fresh attack surface.
6. 6Focus on business-logic bugs, not scan output. Authorization flaws, IDORs, race conditions and privilege escalations pay far more than XSS.
7. 7Write reports in a boring, reproducible template: title, impact, prerequisites, steps to reproduce, request/response, suggested fix. No screenshots without arrows.
8. 8Ship many small, high-quality reports. Triagers reward reliability with faster reviews and cleaner disclosure timelines.
9. 9Never test out-of-scope, never exfiltrate real user data, never brute force. One violation gets you banned from the platform.
10. 10Track hourly rate quarterly. If you drop under $100/hr for 2 consecutive quarters, either switch programs or narrow your specialty (mobile, API, SSRF chains).

Discussion

• No comments yet. Be the first.