Bug Bounty Hunting: How to Find Your First Vulnerability

by

Bug bounty programs pay researchers to find vulnerabilities in real systems before attackers do. In 2026, top bug bounty hunters earn six figures annually — and some of the highest payouts ($50,000–$2,000,000) have gone to researchers who started with no formal security background. This guide covers how to get started, where to hunt, what to look for, and how to write reports that actually get paid.

Choosing Your First Program

The biggest mistake beginners make is targeting Google or Facebook. These programs have thousands of active researchers — any easy bug was found years ago. Instead, focus on programs with wide scope, newer technology, and smaller competition.

  • HackerOne — Largest platform. Filter by “newly launched” programs for the freshest targets
  • Bugcrowd — Large platform with many private programs that have less competition
  • Intigriti — European-focused, excellent payment track record
  • Synack Red Team — Vetted, private programs with higher average payouts
  • Open Bug Bounty — Good for XSS practice, lower payouts but high volume

Program selection criteria: Look for programs with “Anything on *.domain.com” wildcards (more attack surface), recently updated scope (new features = new bugs), and a response time under 7 days (means they take reports seriously).

Recon: Your Competitive Edge

Professional hunters spend 70% of their time on reconnaissance. Finding assets that nobody else is testing is how you consistently find bugs. Automation is key — if you can discover a new subdomain before anyone else and test it immediately, you have a huge advantage.

# Comprehensive subdomain discovery pipeline
# Step 1: Passive discovery
subfinder -d target.com -o subs_passive.txt
amass enum -passive -d target.com -o subs_amass.txt

# Step 2: Brute force
ffuf -u "https://FUZZ.target.com"   -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt   -mc 200,301,302,401,403 -o subs_brute.txt

# Step 3: Combine and deduplicate
cat subs_passive.txt subs_amass.txt subs_brute.txt | sort -u > all_subs.txt

# Step 4: Probe which ones are alive
cat all_subs.txt | httprobe > alive_subs.txt

# Step 5: Screenshot all alive subdomains (spot interesting ones visually)
cat alive_subs.txt | gowitness file -f - --delay 2

What to Look For: High-Value Bug Classes

IDOR (Insecure Direct Object Reference) — Easiest High Impact

# Always test: can I access/modify other users' objects?
# Look for numeric IDs, UUIDs, or usernames in:
# - URL parameters: /api/orders/12345
# - Request body: {"invoice_id": "ABC123"}
# - Headers: X-User-ID: 123

# Test: change ID to another user's known ID
# If you get their data = IDOR = $$$

# Trick: create TWO accounts, use account A to find an object ID, 
# then try to access it with account B's session

Open Redirect — Common, Often Undervalued

# Look for redirect parameters
https://target.com/login?next=https://evil.com
https://target.com/logout?redirect_url=https://evil.com

# Bypass filters:
https://target.com/redirect?url=https://evil.com%2F%40target.com  # domain confusion
https://target.com/redirect?url=//evil.com  # protocol-relative
https://target.com/redirect?url=https://target.com.evil.com  # subdomain trick

# Impact: phishing via legitimate URLs, token stealing in OAuth flows

Subdomain Takeover — Automated and Very Common

# Check if subdomains point to unclaimed cloud services
# (GitHub Pages, Heroku, Shopify, AWS S3, etc.)
cat alive_subs.txt | nuclei -t takeovers/

# Manual check: CNAME points to an unclaimed service?
dig CNAME staging.target.com
# Returns: staging.target.com CNAME target.github.io
# If that GitHub Pages repo doesn't exist, you can claim it!

# Tools specifically for this:
subjack -w all_subs.txt -t 100 -timeout 30 -o takeovers.txt -ssl

Rate Limiting Bypass — Often Missed

# Test: is the OTP/2FA endpoint rate limited?
# Most apps limit by IP -- bypass with:
# 1. Add X-Forwarded-For header with different IPs
for i in {1..100}; do
  curl -X POST https://target.com/api/verify-otp     -H "X-Forwarded-For: 1.2.3.$i"     -d '{"otp":"'$i'0000"}'
done

# 2. Rotate through IPv6 addresses
# 3. Use Burp Turbo Intruder with different IP headers per request

Writing Reports That Get Paid

A perfectly found bug with a poorly written report gets downgraded, duplicated, or ignored. Your report is the product — the bug is just the raw material.

  • Title: Be specific. “IDOR in /api/invoices/{id} allows any authenticated user to view all invoices” beats “Security issue found”
  • Severity: Use CVSS scoring honestly. Inflating severity damages your reputation
  • Impact: Explain the business impact, not just the technical finding. “This allows an attacker to access all customer payment records” is compelling. “There is an IDOR” is not.
  • Steps to Reproduce: Number them. Be exact. Include every header, every parameter, every step. The triage team should be able to reproduce it in under 5 minutes.
  • Proof of Concept: Include screenshots, Burp request/response, and if possible a short video. Never go further than reading data — never modify, delete, or use real user data for PoC.

Your First Month Action Plan

  1. Complete PortSwigger Web Academy top 10 vulnerability labs (free, 2 weeks)
  2. Sign up on HackerOne and read the “Hacktivity” feed — study disclosed reports to understand what bugs look like
  3. Pick one program with wildcard scope and run your recon pipeline on it
  4. Spend one week manually browsing the application — every feature, every form, every API call
  5. Submit your first report — even if it is low severity. The process of writing a report teaches you more than reading about it

Bug bounty hunting rewards patience, methodology, and curiosity in equal measure. The hunters who earn the most are not the ones who know the most hacking techniques — they are the ones who enumerate more thoroughly, test more creatively, and communicate more clearly than everyone else.