[WARN]
Only test within the program's scope document. Testing out of scope is illegal, even if it's "just for practice".
Workflow at a high level
- Pick a program — HackerOne / Bugcrowd / Intigriti, watch the scope and reward history
- Recon — map out as broadly as possible what runs within scope
- Map — which functionality, which technology, where the attack surface sits
- Test — aimed at the highest-yield vulnerability classes for that stack
- Report — clear, reproducible, with an impact assessment
Recon & subdomain enumeration
# Collect subdomains from multiple sources
subfinder -d target.com -o subs.txt
amass enum -passive -d target.com >> subs.txt
# Which subdomains are alive and what runs on them
httpx -l subs.txt -title -status-code -tech-detect
# Discover endpoints/parameters
gau target.com
ffuf -u https://target.com/FUZZ -w wordlist.txtHigh-yield vulnerability classes
- IDOR (often found) — tamper with object IDs in requests, check whether authorization is missing
- Broken access control — reach role-based functions with a lower-role account
- SSRF (good payout) — especially in features that accept a URL as input (webhooks, image-fetch)
- Subdomain takeover — CNAME pointing to a service that is no longer claimed
- Business logic flaws (highest payout, hardest to automate) — race conditions, price manipulation, workflow bypass
Writing a good report
- Title — short and specific, not "found XSS" but "Reflected XSS in search via the
qparameter" - Steps to reproduce — numbered, so someone without context can follow them
- Impact — what an attacker can concretely do with this, not just "it's a vulnerability"
- Evidence — screenshot or short video, no needlessly long payload dumps
- Suggested fix — optional, but it shows you understand the problem
[ TIP ]
Duplicates are the most common rejection for beginners. Speed on newly expanded scope often pays off more than depth on old, picked-over targets.