June 27, 2026 · 16 min read

Bug Bounty Hunting Methodology: A Systematic Approach for Security Researchers

Most bug bounty hunters who don't find bugs aren't missing technical skill — they're missing methodology. They open a target, click around, throw some tools at it, and wonder why experienced hunters consistently outperform them on the same programs.

Systematic hunters map the attack surface before exploiting anything. They understand which vulnerability classes pay and which get triaged as informational. They write reports that get accepted on the first review. This guide covers the full workflow: from reading a program policy to getting paid.

Phase 1: Scope Analysis and Program Research

Before touching the target, spend 30–60 minutes on program research. This separates hunters who waste time on out-of-scope assets from those who find reportable bugs efficiently.

Reading the Policy

The program policy tells you what matters to the company. Read it line by line:

• In-scope vs. out-of-scope assets — wildcards like *.example.com include subdomains; specific domains like api.example.com exclude others. Don't test what isn't listed.
• Vulnerability exclusions — most programs exclude missing security headers, SPF/DKIM, rate limiting on non-sensitive actions, and theoretical/low-impact issues. Check this before spending time on them.
• Safe harbor language — confirms you won't be prosecuted for in-scope testing conducted in good faith.
• Reward tiers — understand what severity actually pays. Some programs cap critical findings at the same amount as high.

# Research the program before testing:
# Check HackerOne/Bugcrowd for disclosed reports on the program
# This tells you what has been found, what gets triaged, and what is informational

# Look for the program's previous disclosures:
# - What vulnerability classes does the program reward?
# - What was marked informational that you might waste time on?
# - Are there historical SSRF/IDOR findings suggesting these classes exist?

# Check the company's tech stack from public sources:
# - LinkedIn job postings (e.g. "must know Kubernetes" → likely Kubernetes)
# - GitHub public repos (tech stack, sometimes credentials in history)
# - BuiltWith / Wappalyzer for frontend stack

Asset Discovery

For wildcard-scoped programs, asset discovery is where you find targets that other hunters haven't exhausted yet.

# Subdomain enumeration:
subfinder -d example.com -o subdomains.txt
amass enum -passive -d example.com -o amass_out.txt
assetfinder --subs-only example.com >> subdomains.txt

# Combine and deduplicate:
sort -u subdomains.txt amass_out.txt | tee all_subs.txt

# Resolve live hosts:
cat all_subs.txt | httpx -status-code -title -tech-detect -o live_hosts.txt

# Port scan in-scope IPs:
cat live_hosts.txt | cut -d' ' -f1 | naabu -top-ports 1000 -o ports.txt

# Screenshot for visual triage:
cat live_hosts.txt | aquatone -out screenshots/

Phase 2: Reconnaissance and Tech Stack Fingerprinting

Targeted recon gives you vulnerability hypotheses before you test a single endpoint. Different stacks have characteristic vulnerability patterns.

# Fingerprint technologies:
whatweb https://app.example.com
wappalyzer-cli https://app.example.com

# Check HTTP response headers for stack clues:
curl -I https://app.example.com
# Server: nginx/1.18 → look for path traversal, alias traversal
# X-Powered-By: Express → Node.js, check prototype pollution, eval injection
# X-Powered-By: PHP/8.1 → type juggling, deserialization
# X-Amz-Request-Id → AWS S3 hosted, check bucket misconfigurations

# Crawl for endpoints:
gospider -s https://app.example.com -o crawl/ -c 10 -d 5
katana -u https://app.example.com -o katana_out.txt -d 5

# Extract JavaScript files for hidden endpoints:
cat live_hosts.txt | getJS --output js_files.txt
cat js_files.txt | xargs -I {} curl -s {} | grep -E "api/|/v[0-9]|endpoint" | sort -u

# Check for exposed API documentation:
for url in $(cat live_hosts.txt); do
  curl -s "$url/swagger.json" | jq '.paths | keys[]' 2>/dev/null
  curl -s "$url/openapi.yaml" 2>/dev/null | grep "^  /"
  curl -s "$url/api-docs" 2>/dev/null | head -20
done

Historical Data Sources

# Wayback Machine for historical endpoints:
waybackurls example.com | tee wayback.txt
gau example.com | tee gau.txt

# Extract parameters from historical URLs:
cat wayback.txt gau.txt | grep "?" | sort -u | tee params.txt

# Find interesting patterns:
cat params.txt | grep -E "redirect|url|next|callback|file|path|id|user|admin"

# Check for exposed secrets in GitHub:
# Search GitHub for: "example.com" api_key
# Search GitHub for: "example.com" password
# Use trufflehog or gitleaks on any public repos

Phase 3: Attack Surface Mapping

Before exploitation, map every distinct attack surface. Prioritize by impact potential.

Authentication Entry Points

• Login, registration, password reset, email verification, OAuth flows
• SSO integrations (SAML, OIDC) — particularly valuable, high impact if broken
• API key management endpoints
• 2FA setup and bypass flows

Authorization Surfaces

• Resources accessible by ID (IDOR candidates): /api/users/{id}, /api/orders/{id}
• Role-based actions (admin endpoints, account switching, privilege escalation paths)
• Multi-tenant isolation (can user A access user B's data?)

File Handling

• Upload endpoints — always test for unrestricted file type, path traversal in filename
• Download/preview endpoints — test for SSRF, path traversal, IDOR
• Import features (CSV, Excel, XML) — check for XXE, formula injection

Integration Points

• Webhook URL fields — SSRF via callback URLs
• URL fetching features (link preview, PDF generation, screenshot services)
• Third-party integrations (OAuth apps, Slack/Jira connectors)

Phase 4: Vulnerability Testing by Class

Work systematically through vulnerability classes rather than testing randomly. Focus on high-impact classes first.

Broken Access Control (IDOR / BOLA)

IDOR is consistently one of the highest-paid vulnerability classes on major programs because impact is clear and undeniable.

# Create two test accounts (Account A, Account B)
# Log in as Account A, capture all requests that include an ID
# Change the ID to Account B's resources

# Find numeric IDs:
# GET /api/invoices/1234 → try 1235, 1236
# POST /api/messages {"to": "user_id_456"} → change to another user

# Find UUID-based IDs (harder to guess, but still test):
# Capture Account B's resource ID while logged in as B
# Switch to Account A and try accessing B's resource ID

# Test horizontal privilege escalation:
# Account A (regular user) accessing Account B's data
# Account A accessing admin endpoints
# Changing account_id or org_id parameters

# Test vertical privilege escalation:
# Regular user → admin actions
# Check if role is validated server-side or just in frontend
curl -H "X-Role: admin" https://api.example.com/admin/users
curl -H "Authorization: Bearer ${regular_token}" https://api.example.com/admin/settings

Server-Side Request Forgery (SSRF)

SSRF in modern cloud environments can lead to cloud credential theft (IMDS access), giving critical or P1 severity.

# Find SSRF entry points:
# - URL fields: webhook URLs, import by URL, link preview, PDF generators
# - Image URL fields: avatar by URL, background image URL
# - XML/JSON with URL values

# Test for blind SSRF with out-of-band detection:
# Use Burp Collaborator, interactsh, or requestbin

curl -X POST https://api.example.com/webhooks \
  -d '{"url": "https://YOUR-COLLABORATOR-URL.oastify.com/test"}'

# Test for cloud metadata access:
curl -X POST https://api.example.com/fetch \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'

# AWS IMDSv1 → credential theft:
# http://169.254.169.254/latest/meta-data/iam/security-credentials/
# http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

# GCP metadata:
# http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Bypass filters:
# http://[::ffff:169.254.169.254]
# http://0x7f000001  (127.0.0.1 in hex)
# http://2130706433  (127.0.0.1 in decimal)
# http://127.1

Business Logic Flaws

These require understanding the application, not just pattern matching. High impact because automated scanners can't find them.

# Price manipulation:
# - Change price to 0 or negative in cart/checkout request
# - Apply coupon codes multiple times via race condition
# POST /checkout {"items": [{"id": 1, "price": 0.01}]}

# Workflow bypass:
# Skip steps in multi-step processes (email verification, KYC)
# Access step N directly without completing step N-1

# Race conditions:
# Concurrent requests for one-time-use resources (gift cards, promo codes)
# Transfer funds simultaneously to exploit double-spend

# Parameter pollution:
# userid=123&userid=456 (which one does the server use?)
# role=user&role=admin

# Negative quantity:
# Add -1 items to receive a credit instead of paying

Phase 5: Automation and Passive Scanning

Run automated scans in the background while doing manual testing. Don't rely on them exclusively — they miss business logic and chain vulnerabilities — but they find low-hanging fruit efficiently.

# Run nuclei with web application templates:
nuclei -u https://app.example.com \
  -t ~/nuclei-templates/vulnerabilities/ \
  -t ~/nuclei-templates/exposures/ \
  -severity medium,high,critical \
  -o nuclei_out.txt

# Run nuclei against all live hosts:
cat live_hosts.txt | nuclei \
  -t ~/nuclei-templates/cves/ \
  -t ~/nuclei-templates/misconfiguration/ \
  -o nuclei_batch.txt

# ffuf for directory/file discovery:
ffuf -u https://app.example.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -mc 200,301,302,401,403 \
  -o ffuf_dirs.txt

# Parameter fuzzing on interesting endpoints:
ffuf -u "https://app.example.com/api/v1/user?FUZZ=test" \
  -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt \
  -mc 200 -fs 512

Phase 6: Chaining Vulnerabilities

Individual low-severity findings that can't be chained often get closed as informational. The skill is recognizing when two minor issues combine into a critical.

Common Chains

Phase 7: Writing Reports That Get Paid

A valid finding with a poor report gets triaged as informational. A clear report with reproduction steps, impact explanation, and a suggested fix gets triaged as critical — and paid faster.

Report Structure

# Title: [Vulnerability Type] in [Feature] leads to [Impact]
# Good: "IDOR in /api/v2/invoices/{id} allows unauthenticated access to all customer invoices"
# Bad: "IDOR found in API"

# Severity: P1/Critical | P2/High | P3/Medium | P4/Low
# CVSS Score (if the program uses it)

## Summary
One paragraph. What is the vulnerability? Where is it? What can an attacker do with it?

## Steps to Reproduce
1. Log in as User A at https://app.example.com
2. Navigate to Settings > Invoices
3. Note invoice URL: https://app.example.com/api/v2/invoices/12345
4. Change 12345 to 12346 (another user's invoice ID)
5. Observe: full invoice data for another user is returned

## Proof of Concept
Include:
- Screenshots or screen recordings
- Raw HTTP requests/responses
- curl commands that reproduce the issue

## Impact
Be specific. "Attacker can access any user's invoice including billing address,
payment method last four digits, and purchase history."

Quantify when possible: "An attacker can enumerate all ~50,000 user invoices
by iterating IDs from 1 to 99999."

## Suggested Remediation
- Verify that the authenticated user owns the requested resource before returning it
- Use authorization checks server-side, not just in the frontend routing

Common Report Mistakes

• Not testing impact — saying "this could allow X" is weak; show that it does allow X with a screenshot
• Missing remediation — programs triage faster when they know what to fix
• Overblown severity — claiming P1 on a self-XSS that requires the victim to paste code into their own browser destroys credibility
• No reproduction steps — triagers reproduce bugs on their own instances; vague steps lead to "cannot reproduce" closures
• Testing on production without permission — always use test accounts; never test with real user data

Vulnerability Class Priority by ROI

Tools Reference

Getting Started: Your First Bug Bounty

Choose a program with a wide scope and a track record of paying. HackerOne's program directory and Bugcrowd's listing show historical statistics — pick programs that have recent paid reports, which indicates active triage and payment.

Start with the methodology in this guide rather than jumping straight to tools. Map the attack surface first. Choose one vulnerability class and test it exhaustively across the entire application before moving to the next. This depth-first approach consistently outperforms scanning randomly with tools.

Document everything. Your notes from program X become reusable context for program Y when the same tech stack or feature set appears. Over time, you'll develop pattern recognition: when you see a webhook URL field, you immediately know to test for SSRF. When you see numeric IDs, you immediately test for IDOR. Methodology becomes intuition.

Key Takeaways

• Spend 30–60 minutes on scope analysis and program research before touching the target — it determines your entire strategy
• Asset discovery on wildcard-scoped programs is where you find untested surfaces
• Map the attack surface before exploiting — authentication flows, authorization surfaces, file handling, and integration points first
• IDOR and SSRF offer the best return on time invested for most modern web applications
• Vulnerability chains often produce critical findings from two medium-severity issues
• Reports with clear reproduction steps, screenshots, and remediation suggestions get paid faster and at higher severity