Your First Bug Bounty: A Step-by-Step Guide

Bug bounty hunting sounds glamorous—hackers earning six figures from their laptops. The reality is more nuanced: it takes time to find your first valid bug, and most hunters don't get rich. But bug bounties offer something valuable: real-world security experience, legitimate income, and a path into the security industry.

This guide covers everything you need to find and report your first vulnerability.

What Is Bug Bounty?

Bug bounty programs pay security researchers to find and report vulnerabilities responsibly. Companies like Google, Microsoft, and thousands of startups run programs because:

• External researchers find bugs internal teams miss
• It's cheaper than getting breached
• Continuous testing beats annual pentests

Typical payouts (2025):

• Low severity: $100-500
• Medium severity: $500-2,000
• High severity: $2,000-10,000
• Critical severity: $10,000-100,000+

Your first bug will likely pay on the lower end. That's normal—and still exciting.

Step 1: Build Your Foundation

Before hunting, you need baseline skills:

Minimum Requirements

• HTTP fundamentals - Requests, responses, headers, cookies
• Browser DevTools - Network tab, console, element inspection
• At least 2-3 vulnerability types - Start with XSS and IDOR
• Burp Suite basics - Intercepting and modifying requests

If these aren't solid, spend 2-4 weeks on fundamentals first. Hunting without basics leads to frustration and duplicate reports.

Recommended Preparation

1. Complete PortSwigger Web Security Academy XSS and access control labs
2. Practice on intentionally vulnerable apps (DVWA, Juice Shop)
3. Read 20+ disclosed bug reports on HackerOne's Hacktivity
4. Try our practice challenges to build confidence

Step 2: Choose Your First Program

Not all programs are suitable for beginners. Here's how to choose:

Platform Comparison

What to Look For

Good first programs have:

1. Large scope - More attack surface = more bugs

   Good: *.example.com (all subdomains)
   Okay: app.example.com
   Hard: Only specific endpoints

1. Responsive team - Check average response times

   Good: <7 days to first response
   Okay: 7-14 days
   Avoid: >30 days or "unresponsive" warnings

1. Beginner-friendly scope - Some programs note this explicitly
2. Clear rules - You should understand what's allowed
3. Recent activity - Programs with recent resolved reports are active

First Program Suggestions

Start with these types:

• Startups - Smaller security teams, more likely to have issues
• Programs accepting all severity levels - Some only want criticals
• Programs with broad wildcard scope - *.example.com
• Programs that pay for duplicates (rare but helpful for learning)

What to Avoid Initially

• FAANG companies - Extremely competitive, well-tested
• Narrow scopes - "Only our login page"
• Programs with long response times - Frustrating for beginners
• Programs requiring special access - Complex onboarding

Step 3: Reconnaissance

Before testing, understand your target:

Subdomain Enumeration

# Using subfinder
subfinder -d example.com -o subdomains.txt

# Using amass
amass enum -d example.com -o subdomains.txt

# Check which are alive
httpx -l subdomains.txt -o alive.txt

Technology Identification

# What tech stack?
whatweb https://example.com

# Check headers
curl -I https://example.com

Manual Exploration

1. Create an account - See authenticated functionality
2. Map all features - What can users do?
3. Note input fields - Every input is a potential attack vector
4. Check robots.txt and sitemap.xml - Often reveal hidden paths
5. Look at JavaScript files - May contain API endpoints, secrets

Document Everything

Keep notes on:

• Subdomains and their purposes
• User roles and permissions
• Interesting parameters
• Technologies used
• Potential attack vectors

Step 4: Testing Strategy for Beginners

Don't try to find everything at once. Focus on high-probability, beginner-friendly vulnerabilities:

Week 1-2: Access Control Issues (IDOR)

IDOR is beginner-friendly because:

• Doesn't require complex payloads
• Very common, especially in APIs
• Easy to understand and explain

Testing method:

1. Create two accounts (attacker, victim)
2. Perform actions as victim, note IDs in requests
3. Try accessing victim's resources as attacker
4. Change IDs in API requests: /api/user/123 → /api/user/124

Common IDOR locations:

• User profile endpoints
• File downloads
• Invoice/receipt access
• Message/notification viewing
• Settings modification

Week 3-4: XSS

Once comfortable with IDOR, try XSS:

Start with reflected XSS:

1. Find a parameter that reflects in the page
2. Test with harmless payload: <test>
3. If reflected, try: <script>alert(1)</script>
4. If blocked, try variations: <img src=x onerror=alert(1)>

Common XSS locations:

• Search functionality
• Error messages
• User profile fields (name, bio)
• Comment systems
• URL parameters reflected in page

Week 5+: Expand

As you get comfortable, add:

• Open redirects
• Information disclosure
• Business logic flaws
• CSRF

Step 5: Writing Your Report

A good report is as important as finding the bug. Poor reports get rejected or underpaid.

Report Structure

## Title
[Vulnerability Type] in [Feature] allows [Impact]

Example: "IDOR in /api/invoices allows any user to download other users' invoices"

## Summary
One paragraph explaining the vulnerability and its impact.

## Steps to Reproduce
1. Log in as user A
2. Create an invoice (note the ID: 12345)
3. Log in as user B
4. Navigate to: https://example.com/api/invoices/12345
5. User B can download User A's invoice

## Impact
What can an attacker actually do? Be specific:
- Access to PII (names, addresses, payment info)
- Financial impact (downloading paid content for free)
- Account takeover potential

## Proof of Concept
[Screenshots, video, or working code]

## Suggested Fix
How would you fix this? (Optional but appreciated)

## Environment
- Browser: Chrome 120
- OS: macOS
- Account used: test@example.com

Report Tips

Do:

• Be clear and concise
• Include exact URLs and parameters
• Show impact from business perspective
• Provide reproducible steps anyone can follow
• Include timestamps if relevant

Don't:

• Exaggerate severity
• Include irrelevant findings
• Write walls of text
• Assume the reader knows context
• Be rude or demanding

Example: Good vs. Bad Report

Bad:

Found XSS on your site. It's really bad, you should fix it ASAP. Let me know when bounty is ready.

Good:

Reflected XSS in search parameter

>

The search functionality at https://example.com/search reflects user input without sanitization.

>

Steps:

1. Navigate to https://example.com/search?q=<script>alert(document.domain)</script>

2. JavaScript executes in context of example.com

>

Impact: An attacker could craft a malicious URL and send it to victims. When clicked, the attacker's JavaScript runs in the victim's session, enabling cookie theft, session hijacking, or phishing.

>

PoC: [Screenshot attached]

Step 6: After Submitting

Response Times

Expect:

• Acknowledgment: 1-7 days
• Triage decision: 1-4 weeks
• Resolution: Weeks to months
• Payment: After fix is deployed

Handling Responses

If accepted: Great! Wait for payment and disclosure timeline.

If marked duplicate: Someone found it first. This is normal—don't be discouraged. Ask what was different about the original report to learn.

If marked informational: The team doesn't see it as a security issue. You can politely ask for clarification, but don't argue.

If rejected: Ask for specific feedback. Sometimes reports are rejected for:

• Not demonstrating real impact
• Out of scope
• Expected behavior
• Missing reproduction steps

Building Reputation

• Consistent valid reports build reputation
• Higher reputation = invites to private programs
• Private programs = less competition, better payouts

Common Beginner Mistakes

1. Hunting Without Preparation

Problem: Running automated scanners without understanding what they find.

Solution: Learn to find and validate bugs manually first.

2. Reporting Self-XSS

Problem: XSS that only affects the attacker themselves.

Solution: XSS must affect other users. If you have to convince a victim to paste JavaScript into their console, it's self-XSS.

3. Duplicates From Public Sources

Problem: Reporting vulnerabilities found in public Nuclei templates or scanners.

Solution: If a tool finds it automatically, hundreds of others already reported it.

4. Over-Inflated Severity

Problem: Marking everything as critical.

Solution: Use CVSS calculator honestly. Programs know when severity is inflated.

5. Giving Up After No Response

Problem: Assuming silence means rejection.

Solution: Wait the stated SLA, then follow up politely. Teams are busy.

6. Burning Out

Problem: Hunting 8 hours daily, finding nothing, quitting.

Solution: Start with 1-2 hours a few times per week. Quality > quantity.

Realistic Expectations

Time to First Bug

• Fast: 1-2 weeks (some luck involved)
• Average: 1-2 months
• Normal: 3-6 months

Most beginners quit before finding their first bug. Persistence matters.

Early Income

First year realistically:

• Part-time hobbyist: $0-5,000
• Dedicated beginner: $5,000-20,000
• Full-time grinder: $20,000-50,000

Some make more, many make less. Don't quit your job based on bug bounty dreams.

The Path Forward

Bug bounty can lead to:

• Full-time security roles (many companies hire from their bounty programs)
• Consulting/pentesting careers
• Security tool development
• Training and education

Your First Month Checklist

Week 1:

• [ ] Choose a platform (HackerOne recommended)
• [ ] Select 3 beginner-friendly programs
• [ ] Set up Burp Suite
• [ ] Read 10 disclosed reports in your target's category

Week 2:

• [ ] Complete recon on one program
• [ ] Create test accounts
• [ ] Map all functionality
• [ ] Document potential attack vectors

Week 3:

• [ ] Test for IDOR on 5 endpoints
• [ ] Test for reflected XSS in 5 parameters
• [ ] Keep detailed notes of everything tested

Week 4:

• [ ] Submit your first report (even if uncertain)
• [ ] Learn from the response
• [ ] Adjust strategy based on feedback
• [ ] Continue testing

Start Hunting

The only way to find your first bug is to start looking. Pick a program, start exploring, and remember: every experienced hunter was once a beginner with zero finds.

Practice your skills on our security challenges before testing real programs, then apply what you've learned to actual targets.

Good luck!

---

Bug bounty landscape changes constantly. This guide will be updated as platforms and strategies evolve. Last updated: December 2025.