Bug Bounty Hunting — From Beginner to First Valid Report

What Is Bug Bounty Hunting?

Bug bounty programmes are agreements where organisations pay researchers to find and responsibly disclose security vulnerabilities. Companies get crowdsourced security testing from thousands of skilled researchers; researchers get legal permission to test and financial rewards for valid findings.

The global bug bounty market pays out over $300 million annually. Top researchers earn six-figure incomes. The median payout for a critical vulnerability on HackerOne is approximately $10,000. But most beginners make nothing for the first 3-6 months — the learning curve is steep, competition is intense, and skill development takes time.

The Major Platforms

Programme Types

Bug bounty programme types:

Public programme:
  - Open to all registered researchers
  - Higher competition (more hunters looking)
  - Good starting point — no invitation needed

Private / invitation-only programme:
  - Invitation based on reputation, skills, or previous reports
  - Less competition — higher chance of finding bugs
  - Accessed by building reputation on public programmes first

Vulnerability Disclosure Programme (VDP):
  - No monetary reward — recognition and thanks only
  - Useful for building reputation if bounties are blocked
  - Many government agencies run VDPs (US Air Force, DoD)

Live hacking event (LHE):
  - In-person or virtual events with select researchers
  - Coordinated time window; bonuses for critical findings
  - By invitation (usually top-ranked researchers)

Private bug bounty (direct with company):
  - Company hires you directly as a researcher
  - Negotiated scope and terms
  - Typically for senior researchers with track record

Choosing the Right Programme

Not all programmes are equally good for beginners. Wide scope, active response, and fair payouts make the difference between a productive hunting experience and months of frustration.

Programme Selection Criteria

Evaluate a programme before spending time on it:

1. Scope — what can you test?
   GOOD: "*.example.com" (wildcard — many assets, more attack surface)
   BAD:  "www.example.com/contact-us only" (one page — nothing to find)
   Check: Does scope include APIs, mobile apps, infrastructure?

2. Response time and ratio
   On HackerOne: check "median time to first response" and "% resolved"
   GOOD: < 5 days first response, > 80% resolved rate
   BAD:  > 30 days first response — reports go unread for weeks

3. Payout reputation
   Check HackerOne's "Hall of Fame" and researcher comments
   Red flags: "we don't pay for this type of vulnerability" applied inconsistently
   Look for: clear severity-to-payout table in the programme policy

4. Competition level
   New private programme: few researchers, many uncharted bugs
   Mature public programme (Google, Facebook): extremely competitive, most bugs found

5. Technology stack
   Match your skills to the programme:
   - Strong in PHP/WordPress: target smaller companies with WordPress sites
   - Strong in API security: target API-heavy platforms
   - Strong in iOS/Android: look for mobile-focused programmes

Beginner-friendly programmes to start with:
  - US DoD Vulnerability Disclosure Program (hackerone.com/dod)
  - HackerOne public programmes with recent activity
  - Bugcrowd's university/student-friendly programmes
  - PortSwigger Web Security Academy (learning labs, not a real programme,
    but best training resource available)

Reading the Policy — What NOT to Test

Critical policy reading — you are legally bound by the scope:

Always check for explicit exclusions:
  - "Denial of service attacks are out of scope" — never test DoS
  - "Social engineering is out of scope" — no phishing of employees
  - "Third-party services are out of scope" — don't test their vendors
  - "Rate limiting is not a valid finding" — they won't pay for it

Test environment vs production:
  Some programmes want testing ONLY on staging environments
  NEVER test on production systems if policy says staging only
  If unclear: ask the programme's triage team BEFORE testing

Data handling requirements:
  "Do not exfiltrate data" — even if you find SQLi, do not download the DB
  "Do not access other users' data" — use your own test accounts
  "Do not modify or delete data" — read-only exploitation only

Safe harbour language:
  Most good programmes include "safe harbour" stating they won't pursue legal action
  for good-faith testing within scope. Verify this clause exists before testing.
  Without it: even legitimate testing may have legal risk (CFAA in the US).

Recon Workflow for Bug Bounty

Bug bounty hunting is primarily a recon game — most successful hunters spend 60-70% of their time on reconnaissance to build a comprehensive map of the attack surface before touching any specific endpoint.

Subdomain Enumeration

# Comprehensive subdomain enumeration workflow

# Step 1: Passive enumeration (no direct contact with target)
# amass — comprehensive OSINT-based enumeration
amass enum -passive -d example.com -o amass_passive.txt

# subfinder — fast, many data sources
subfinder -d example.com -o subfinder.txt -all

# crt.sh — certificate transparency logs
curl -s "https://crt.sh/?q=%.example.com&output=json" |   jq -r '.[].name_value' | sort -u > crtsh.txt

# Combine all sources
cat amass_passive.txt subfinder.txt crtsh.txt | sort -u > all_subdomains.txt
wc -l all_subdomains.txt   # know your attack surface size

# Step 2: Resolve live hosts
# httpx — probe which subdomains have live web servers
httpx -l all_subdomains.txt -o live_hosts.txt   -status-code -title -tech-detect -follow-redirects

# Step 3: Screenshot all live hosts
# gowitness — take screenshots at scale
gowitness file -f live_hosts.txt --screenshot-path ./screenshots/

# Step 4: Identify interesting targets from screenshots
# Look for: admin panels, login pages, unusual apps, internal-looking pages
# Most valuable: internal tools accidentally exposed, dev/staging environments

Content Discovery

# Find hidden endpoints, admin panels, backup files

# ffuf — fast web fuzzer (best for directory/endpoint discovery)
# Standard directory discovery
ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt   -mc 200,201,301,302,401,403 -t 50 -o ffuf_dirs.json

# API endpoint discovery (REST API pattern)
ffuf -u https://api.target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt   -H "Authorization: Bearer YOUR_TOKEN" -mc 200,201,401

# Backup file discovery (common mistake — backup files left in web root)
ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt   -e .bak,.old,.zip,.tar.gz,.sql,.env,.config -mc 200

# Parameter discovery (finding hidden parameters)
arjun -u https://target.com/api/user -m GET

# JavaScript file analysis (find hidden endpoints in JS)
# LinkFinder — extracts endpoints from JS files
python linkfinder.py -i https://target.com -d -o results.html

# Wayback Machine — historical endpoint discovery
# Find old endpoints that may still work
gau target.com | grep -E ".js$" | sort -u > js_files.txt
gau target.com | grep -E "api|admin|login" | sort -u > interesting_urls.txt

GitHub Intelligence for Bug Bounty

# Companies often accidentally commit secrets, internal URLs, and API keys

# Search GitHub for company-related secrets
# Manually search: site:github.com "example.com" AND ("api_key" OR "password" OR "secret")

# truffleHog — scan GitHub repos for secrets
trufflehog github --org=targetcompany --only-verified

# gitrob — find sensitive files in GitHub organisations
gitrob analyze targetcompany

# What to look for in GitHub:
# 1. Hardcoded API keys (Stripe, Twilio, AWS, Slack)
# 2. Internal hostnames and IP addresses (admin panels, internal APIs)
# 3. Database connection strings (often in config files)
# 4. Commented-out code with credentials
# 5. Old branches with different security controls
# 6. .env files accidentally committed

# Common high-value finds:
# - AWS_ACCESS_KEY_ID in a config file → cloud account access
# - Stripe secret key → payment processing control
# - Internal API documentation revealing undocumented endpoints

Technology Fingerprinting

# Identify the technology stack to focus your attack

# whatweb — technology identification
whatweb https://target.com -v -a 3

# Wappalyzer (browser extension or CLI)
wappalyzer https://target.com

# Shodan — identify the infrastructure
shodan host 93.184.216.34    # search by IP
# Or search by org: shodan search org:"Target Company"

# wafw00f — detect WAF (important for testing approach)
wafw00f https://target.com

# Information from stack:
# WordPress → check for plugin vulnerabilities (wpvulndb.com)
# React SPA → look for client-side vulnerabilities, exposed API endpoints
# GraphQL → introspection enabled? IDOR via direct object references?
# Spring Boot → Actuator endpoints exposed? (/actuator/env, /actuator/heapdump)
# Django DEBUG=True → exposed debug page with settings
# PHP → file inclusion, RCE via upload if misconfigured

High-Value Vulnerability Classes

Focus on vulnerabilities with the highest expected payout-to-effort ratio. Automated scanners catch the easy stuff — what pays is what requires manual analysis and creative chaining.

IDOR — Insecure Direct Object Reference

IDOR is the most common high-severity finding in bug bounty programmes.
It occurs when you can access another user's resources by changing an identifier.

Basic IDOR discovery:
  1. Create two test accounts (attacker: A@mail.com, victim: B@mail.com)
  2. Log in as B and perform actions: create documents, orders, profile updates
  3. Log in as A and attempt to access B's resources using observed IDs
  4. If A can read/modify/delete B's data: IDOR found

Common IDOR patterns:

// Numeric ID in URL — most obvious, often caught
GET /api/users/1234/profile    → try 1235, 1236

// UUID — harder, but worth testing
GET /api/orders/550e8400-e29b-41d4-a716-446655440000
// Find victim UUID from: email notifications, shared links, source code

// Indirect IDOR — through a reference object
POST /api/export
{"report_id": 42}   → change to another user's report_id

// IDOR in file download
GET /files/download?filename=invoice_1234.pdf
→ try invoice_1235.pdf, invoice_1.pdf

// IDOR via HTTP method change
PUT /api/users/1234   (your account)
PUT /api/users/1235   (another user — should be forbidden)

Burp Suite automation:
  - Use Intruder with a range payload (1-10000) on the user ID
  - Filter responses by unique response length (different length = different data)
  - Autorize extension: auto-tests all requests with a different user's cookie

OAuth and Authentication Misconfigurations

OAuth/SSO bugs can lead to account takeover — top-tier payouts

1. State parameter CSRF:
   // OAuth flow should include unpredictable state parameter
   GET /oauth/authorize?client_id=app&redirect_uri=...&state=RANDOM_VALUE
   // If state is missing or predictable: CSRF attack possible
   // Can lead to: account linking hijack (attacker's account linked to victim)

2. Open redirect in redirect_uri:
   // Some providers allow partial matching on redirect_uri
   GET /oauth/authorize?client_id=app&redirect_uri=https://evil.com/
   // If accepted: authorization code stolen by attacker's server

3. Code/token leakage in Referer header:
   // OAuth code appears in URL → if page loads third-party resources,
   // code appears in the Referer header of those requests
   GET /callback?code=SECRET_CODE  → loads analytics.js → Referer: /callback?code=SECRET_CODE
   // Result: code leaked to analytics provider

4. Token fixation in OAuth PKCE:
   // PKCE code_challenge must be validated against code_verifier
   // If validation is skipped: code interception attack possible

5. Insufficient token validation:
   // App accepts JWT tokens with any signature ("alg: none" attack)
   // Change "alg": "RS256" to "alg": "none" → remove signature → forge any claims

// Testing OAuth with Burp:
// 1. Capture entire OAuth flow in Proxy
// 2. Identify state, code, redirect_uri parameters
// 3. Replay requests with modified parameters
// 4. Check: does state change between requests? Is redirect_uri validated exactly?

SSRF — Server-Side Request Forgery

SSRF lets you make the server send requests to internal services

High-impact SSRF targets:
  - AWS EC2 IMDS: http://169.254.169.254/latest/meta-data/iam/security-credentials/
  - GCP metadata: http://metadata.google.internal/computeMetadata/v1/
  - Azure IMDS: http://169.254.169.254/metadata/instance?api-version=2021-02-01
  - Internal services: Redis, Elasticsearch, internal APIs (http://localhost:6379)

Common SSRF injection points:
  - URL/webhook parameters: ?url=, ?webhook=, ?callback=, ?image=
  - PDF generators (often fetch external URLs)
  - Import/export features (import from URL)
  - Image processors

# SSRF testing workflow:
# 1. Set up an out-of-band receiver (Burp Collaborator or interactsh)
interactsh-client   # generates a unique URL: abc123.oast.pro

# 2. Submit your collaborator URL in SSRF candidates
POST /api/process-url
{"url": "http://abc123.oast.pro/test"}

# 3. Check collaborator for DNS/HTTP callbacks (proves SSRF)
# 4. If callback received: test cloud metadata URL for credentials

# SSRF bypass techniques (when naive filter blocks 169.254.x.x):
# IPv6: http://[::ffff:a9fe:a9fe]/latest/meta-data/
# Decimal: http://2852039166/latest/meta-data/
# Hex: http://0xa9fea9fe/latest/meta-data/
# URL shortener redirect: https://tinyurl.com/→ 169.254.169.254
# DNS rebinding: DNS resolves to internal IP after WAF check

Business Logic Vulnerabilities

Business logic bugs are manual-only — scanners cannot find them
They often have high payout because they require understanding the application flow

Common business logic patterns:

1. Price manipulation:
   POST /cart/update {"item_id": 1, "quantity": 1, "price": 0.01}
   // Does server trust client-submitted price? If yes: buy anything for $0.01

2. Coupon/discount abuse:
   // Apply same coupon multiple times
   // Apply coupon to items explicitly excluded by terms
   // Chain multiple discount types not intended to stack

3. Race conditions (concurrent requests):
   // Two simultaneous requests to redeem a gift card
   // Two simultaneous transfers from same account
   // Use asyncio or Turbo Intruder (Burp extension) for parallel requests

   import asyncio, aiohttp
   async def redeem(session, code):
       async with session.post("/redeem", json={"code": code}) as r:
           return await r.json()

   async def race():
       async with aiohttp.ClientSession() as s:
           results = await asyncio.gather(*[redeem(s, "GIFT100") for _ in range(10)])
   asyncio.run(race())

4. Account takeover via password reset:
   // Request reset for victim@example.com
   // Check if host header injection changes the reset link domain
   POST /forgot-password
   Host: attacker.com
   {"email": "victim@example.com"}
   // If reset email contains http://attacker.com/reset?token=xxx → token stolen

5. Mass assignment:
   // PATCH /api/users/me  {"name": "new name", "role": "admin"}
   // If server blindly applies all submitted fields: privilege escalation

Writing a High-Quality Bug Report

A mediocre vulnerability reported brilliantly pays more than a brilliant vulnerability reported mediocrely. Triage teams process hundreds of reports — clear, reproducible, impact-focused reports get prioritised and paid faster.

Report Structure

Bug bounty report template:

**Title:** [Vulnerability Type] in [Component] — [Impact Summary]
Example: "IDOR in /api/users/{id} allows reading any user's private profile data"

**Severity:** Critical / High / Medium / Low
(Use CVSS v3.1 calculator for objective scoring)

**Description:**
2-3 sentences: what is the vulnerability, where is it, and what can an attacker do?
"The /api/v2/documents/{document_id} endpoint fails to verify that the
authenticated user owns the requested document. An attacker can enumerate
document IDs and read any user's private documents without authorisation."

**Steps to Reproduce:**
(Numbered, exact, reproducible — triage must be able to follow these)

1. Create two accounts:
   - Victim: victim@test.com (account ID: 54321)
   - Attacker: attacker@test.com (account ID: 54322)

2. Log in as victim@test.com and create a private document.
   Note the document ID from the URL: /documents/99887

3. Log out. Log in as attacker@test.com.

4. Send the following request:
   GET /api/v2/documents/99887
   Host: app.example.com
   Authorization: Bearer [attacker's token]

5. Observe: the response contains the victim's private document content.

**Impact:**
"An attacker can read all private documents belonging to any user by
enumerating document IDs (which are sequential integers from 1 to N).
This exposes potentially sensitive personal and business data of all
users on the platform. Estimated exposure: all N documents."

**Proof of Concept:**
[Screenshot: attacker's browser showing victim's document]
[Screenshot: response headers showing 200 OK with victim's content]
[Optional: short video walkthrough]

**Suggested Remediation:**
"Verify that the authenticated user's ID matches the document's owner_id
before returning document content. Example: SELECT * FROM documents
WHERE id = ? AND owner_id = current_user_id"

CVSS Scoring — Communicate Impact Objectively

CVSS v3.1 scoring for bug bounty reports:

Key metrics:
  Attack Vector (AV):      Network (N) / Adjacent (A) / Local (L) / Physical (P)
  Attack Complexity (AC):  Low (L) / High (H)
  Privileges Required (PR): None (N) / Low (L) / High (H)
  User Interaction (UI):   None (N) / Required (R)
  Scope (S):               Unchanged (U) / Changed (C)
  Confidentiality Impact:  None (N) / Low (L) / High (H)
  Integrity Impact:        None (N) / Low (L) / High (H)
  Availability Impact:     None (N) / Low (L) / High (H)

IDOR example scoring:
  AV:N / AC:L / PR:L / UI:N / S:U / C:H / I:N / A:N
  = CVSS 6.5 (Medium) for reading own-scope data

  AV:N / AC:L / PR:L / UI:N / S:C / C:H / I:H / A:N
  = CVSS 9.1 (Critical) if scope changed (admin data) or write access

Use the NVD CVSS calculator: nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Common Report Rejection Reasons

Building Your Bug Bounty Workflow

Automation Framework

# Automated monitoring for new scope and new subdomains
# When programmes add new domains, you want to be first on them

# notify — alert you on new subdomains
amass enum -passive -d example.com | anew known_subdomains.txt | notify -provider slack

# Fresh asset workflow (run daily via cron)
#!/bin/bash
TARGET="example.com"
DATE=$(date +%Y-%m-%d)

# Enumerate subdomains
subfinder -d $TARGET -all -silent | anew subdomains_$TARGET.txt |   # Probe only new subdomains
  httpx -silent -status-code -title -tech-detect |   anew live_hosts_$TARGET.txt |   # Alert on new live hosts
  notify -provider discord -bulk

# Nuclei scan on new hosts
cat live_hosts_$TARGET.txt |   nuclei -t technologies/ -t exposures/ -t cves/     -severity critical,high -silent |   notify -provider slack

# Track programme changes
# Follow @ariane or use h1-update-bot to track HackerOne programme changes

Burp Suite Configuration for Bug Bounty

Essential Burp Suite setup for bug bounty:

Extensions to install (BApp Store + GitHub):
  Autorize:        Auto-test access control on all requests with a second account cookie
  Param Miner:     Discover hidden parameters via header/query fuzzing
  JS Miner:        Extract endpoints and secrets from JavaScript files
  403 Bypasser:    Test path-based authorization bypass techniques
  JWT Editor:      Modify and test JWT tokens (alg:none, key confusion)
  Turbo Intruder:  High-speed fuzzing for race conditions and rate limit testing
  Active Scan++:   Enhanced active scanning rules
  GAP:             Gather endpoints from JS and responses

Scope configuration:
  1. Add target to scope (Target > Scope > Add)
  2. Check "Use advanced scope control"
  3. Add wildcards: *.example.com
  4. Set proxy to filter in-scope only (reduces noise)

Useful Burp workflow:
  1. Crawl app while logged in — Burp captures all requests
  2. Review Target > Site Map for all observed endpoints
  3. Right-click any endpoint: "Send to Repeater" for manual testing
  4. Autorize: paste victim's cookie → all future requests auto-tested for IDOR
  5. Export full request list for ffuf wordlist generation

Responsible Disclosure Ethics

Bug bounty ethics — be the researcher you would want testing your own systems:

DO:
  ✓ Test only in-scope assets and vulnerability types
  ✓ Use your own test accounts; never access real user data
  ✓ Stop testing once you have proof of concept — do not go further than needed
  ✓ Report promptly — do not hoard vulnerabilities
  ✓ Give companies reasonable time to fix before public disclosure (90 days typical)
  ✓ Communicate professionally — triage are people doing their job

DON'T:
  ✗ Exfiltrate user data (even to prove impact — describe the exposure, do not download it)
  ✗ Modify or delete data
  ✗ Perform DoS attacks
  ✗ Escalate beyond demonstrating the vulnerability
  ✗ Threaten to publish unless paid (this is extortion — it is illegal)
  ✗ Share unpatched vulnerabilities publicly before disclosure period expires
  ✗ Test out of scope assets even if you find something interesting
  ✗ Use automated scanners aggressively against production systems

On grey areas — when in doubt, ask:
  "Is [X] in scope? I found [general description] and want to confirm I can test it"
  Better to spend 5 minutes confirming scope than to get a report rejected or face legal risk.