Bug Bounty Methodology

Beginners lose before testing by choosing bad targets. Read the policy, always:

• Scope: *.example.com (wildcard) vs exact hosts. Out-of-scope = instant ban territory. Note what’s explicitly excluded (third-party SaaS, certain vuln classes).
• Rewards: public tables tell you severity payouts. New programs on HackerOne/Bugcrowd/Intigriti = fewer hunters sitting on the surface.
• Rules of engagement: rate limits, allowed scanners, safe harbor language, response SLAs. Programs with slow triage eat your motivation.

Strategy for the first six months: pick ONE wide-scope program and go deep instead of five shallow. Depth beats novelty — you learn the app, notice anomalies, and build asset knowledge nobody else has.

Recon is a funnel, not a command:

# 1. enumerate subdomains (multiple sources)
subfinder -d target.com -silent
# + crt.sh certificate transparency, passive sources
# 2. resolve which are alive
httpx -l subs.txt -title -tech-detect -status-code
# 3. fingerprint tech & find the weird ones
# 4. content discovery on promising hosts
ffuf -u https://host/FUZZ -w wordlist.txt -mc 200,301,302

Then archive everything: Wayback Machine URLs (waybackurls) reveal old endpoints still deployed — forgotten functionality is bug paradise. Take notes per host; screenshots help future-you recognize “that login page looked different last week”.

Automation mindset: wrap the funnel in scripts so it re-runs weekly against your chosen program. New subdomain appears = first one testing it. The full workflow lives in Karabo’s recon guide.

Highest signal-to-effort bugs for newcomers:

• IDOR everywhere: every numeric/hash ID in every endpoint → swap between two test accounts. Check APIs, mobile apps, exports, email links.
• Information disclosure: exposed .git, debug endpoints, stack traces with versions, directory listings, juicy comments in JS bundles (grep -r "api\|secret\|TODO").
• Auth quirks: password reset token reuse, no rate limit on OTPs, registration flows letting you pick admin roles.
• Subdomain takeovers: dangling CNAMEs to unclaimed cloud pages — fully automatable detection.

The discipline that separates hunters from noise-submitters: validate impact. An IDOR proving you can read another user’s invoice with PII = report. A 403 that looks bypassable but isn’t = note it and move on. Duplicate prevention tip: search the program’s disclosed reports first — reading others’ findings teaches the app’s weak spots too.

Triagers skim. Structure wins:

• Title = one-line impact: “IDOR exposes any user’s billing address via /api/v1/invoices/{id}” — not “found security issue”.
• Severity with justification (CVSS helps but explain business impact in plain words).
• Steps to reproduce: numbered, copy-pasteable requests (raw HTTP), starting from a FRESH account state.
• Proof: screenshot showing another user’s data + curl one-liner for validation.
• Remediation: object-level authorization checks server-side; UUIDs alone aren’t a fix.

Tone: collaborative, zero attitude. When duplicates happen or severity gets downgraded, respond with evidence calmly — reputation compounds across programs. Study structure in the site’s writeups, keep your template in one place, and log every finding even the rejected ones — that journal becomes your personal vulnerability playbook.