Choosing Targets & Programs
> Where you point your effort matters more than how hard you hit. This page distills the > target-selection judgment that separates high-earning reports in this corpus from the noise. > General background is marked; specific patterns link to the class pages.
§Pick programs by your edge, not by brand
- Wide scope > narrow scope.
*.target.comand "all acquisitions" beat a single app — more
surface, more forgotten hosts, fewer hunters per endpoint.
- New scope / new features are underhunted. When a program adds an asset or ships a feature,
the low-hanging fruit resets. Watch changelogs, /blog, release notes, and app-store updates.
- Match the tech to your skills. GraphQL-heavy? Hunt GraphQL BOLA/introspection. Reversing? Hunt
mobile and thick clients. Infra? Hunt SSRF/subdomain-takeover/cloud misconfig.
- Responsiveness & signal. Fast triage, fair severity, and disclosure (so you can learn) beat a
higher theoretical payout that never triages.
§Pick assets by expected input-reaches-code density
Rank in-scope assets by how much untrusted input reaches privileged code:
| High ROI | Why |
|---|---|
| API gateways, GraphQL endpoints | Object-level authz is hard; BOLA/BFLA everywhere |
| "Import from URL" / preview / screenshot / PDF | Server fetches attacker URLs → SSRF/XXE |
| File upload + server-side processing | Upload→RCE, image parser bugs, XXE in office formats |
| Multi-tenant apps | Tenant isolation breaks = one bug, every customer |
| Auth/SSO/OAuth/reset flows | Account takeover; small logic slips = critical |
| Admin & internal tooling subdomains | Weak authz, debug endpoints, verbose errors |
| Webhooks / integrations / OAuth apps | SSRF, secret leakage, redirect_uri abuse |
Deprioritize (still test, but expect noise): static marketing sites, pages with no state-changing actions, endpoints with no IDs/params.
§Read the program's own hints
- Out-of-scope & known-issues tell you what's already been reported — and what's nearby and
untested. If self-XSS is out of scope, look for a delivery vector that makes it not-self.
- Severity/bounty table reveals what they fear (usually: ATO, RCE, SSRF-to-internal, PII).
- Past disclosed reports (this corpus!) show the app's recurring weak spots — the same class
often recurs after a patch as a variant (see §2.3 merge cases on class pages).
§The variant-hunting mindset
The cheapest critical is the sibling of a patched bug. When you find (or read) one report:
- Re-test the same class on adjacent params/endpoints/tenants.
- Check whether the fix is complete (encoding one context but not another, blocking one scheme but
not gopher:/dict:, filtering 127.0.0.1 but not [::1]/0.0.0.0/decimal IP).
- Diff old vs new API versions — the old one may keep the bug.
§Effort budgeting
- Timebox recon; switch to testing once you have a param list and a shortlist of juicy features.
- When an app is hardened, pivot to logic — race conditions, workflow skips, price/quantity abuse
— which scanners and other hunters miss. (See vulnerabilities/business-logic/.)
- Chain low findings into high impact: open-redirect + OAuth = token theft; IDOR + info-leak = ATO.
The chains/ page catalogs real multi-bug escalations from the corpus.
§References
- Cross-links:
methodology/recon.md,methodology/triage-and-impact.md,chains/README.md. - Reference books: Bug Bounty Bootcamp (Choosing a Bug Bounty Program), Real-World Bug Hunting.