Good bug bounty work is less about running every scanner and more about building an accurate map of the target. The map tells you where the application trusts input, where identities cross boundaries, and which old-looking surface still receives production traffic.
Start with scope, not tools
Read the program policy before collecting anything. Record the allowed domains, excluded paths, rate limits, authentication rules, and whether automated scanning is permitted. A technically valid finding can still be invalid if it crosses the program boundary.
Build a small asset inventory
Collect subdomains, resolved hosts, visible technologies, login surfaces, API prefixes, and meaningful redirects. Keep the output in a dated file so you can distinguish a new observation from an old one. Remove duplicates before testing anything.
The useful question is not “how many hosts exist?” It is “which hosts expose a different trust boundary or application?” A staging panel, an upload service, and an API gateway deserve different attention than ten identical CDN aliases.
Validate manually
For each promising surface, confirm:
- The host is in scope and responds consistently.
- The behavior is reproducible without excessive requests.
- The input reaches a meaningful security boundary.
- The impact can be explained without accessing unrelated user data.
Stop when the impact is proven. A minimal proof is safer and easier to report than a broad exploit chain.
Write the report while testing
Capture the exact request shape, a redacted response, affected endpoint, expected behavior, actual behavior, impact, and a short reproduction path. Clear evidence helps a triager reproduce the issue without guessing what the researcher did.
Recon creates possibilities. Manual validation turns one of them into a report.