Bug Bounty Hunting: Getting Started

Bug bounty programs exist because finding security vulnerabilities is expensive and difficult at scale. Companies that run mature programs have concluded that paying external researchers to find bugs is cheaper than getting breached. Google's Vulnerability Reward Program has paid out over $50 million since 2010. HackerOne's top earners have made over $2 million each. The 20-year-old who found a critical iOS zero-click vulnerability from his bedroom and received a $300,000 Apple Security Bounty payout is not a myth.

Getting there, however, is not what YouTube thumbnails suggest. This is a methodical, technical discipline that requires real skill, patience, and a systematic approach. This guide covers what actually produces results — not the theory, but the workflow, tools, and decision-making process that separates researchers who make money from those who generate a lot of invalid reports.

The Platforms: Where Programs Live

HackerOne

The largest bug bounty platform by program count and total payout volume. As of 2025, HackerOne has paid out over $300 million to researchers. The platform has two program types:

Public programs are open to anyone with a verified HackerOne account. They're more competitive — every researcher with an account has access — but they're also where you learn. The Hacktivity feed shows recently disclosed reports with payout amounts, and disclosed reports from programs you're targeting are the most valuable free learning resource in the industry.

Private programs are invite-only, extended based on your reputation score and signal (valid report rate). Private programs typically have less competition, broader scope, faster response times, and higher payouts. Getting invited requires building a track record on public programs first.

Signal score matters. HackerOne tracks the percentage of your reports that are valid vs. invalid/spam/duplicate. A low signal score limits your invitations to private programs. Don't report unless you have high confidence it's valid.

Bugcrowd

Similar model to HackerOne with a heavier enterprise focus. Bugcrowd's triage team handles first-pass validation before reports reach the program — which means slower initial feedback but more consistent responses. Their "VRT" (Vulnerability Rating Taxonomy) provides a standardized severity framework that's useful for calibrating your own severity assessments.

Bugcrowd also runs a platform called Pen Testing as a Service (PTAAS), which is closer to structured consulting engagements than open bounty hunting.

Intigriti

Europe-based with a strong mid-market program selection. Scope overlap with HackerOne is relatively low, so running both platforms in parallel is worthwhile. GDPR-compliant programs often appear here first before expanding to US-based platforms. Response times tend to be fast.

Synack

A curated, vetted network. You apply and go through a vetting process (including a technical skills assessment). Synack pays researchers for time in addition to bounties, which provides more predictable income. The downside: it's not open enrollment. Getting in takes demonstrable skill.

Specialized Platforms

Federacy and NCSC coordinated vulnerability disclosure (Netherlands) cover government and public sector targets. These programs often have the cleanest, least-competed-on scope — and in the Netherlands, an effective legal framework that protects researchers who follow the rules.

HackerOne's "Programs Without Bounties" — responsible disclosure programs that don't pay. Still worth testing: they build your profile, often lead to Hall of Fame acknowledgments, and the skills transfer to paid programs.

Target Selection: Where Most Beginners Waste Time

Program selection is the highest-leverage decision you make. Choosing the wrong target costs weeks.

What to Avoid

Programs with very broad scope and zero payout history. Check the "average bounty" and "reports resolved" stats on the program page. If a program has been live for two years and paid out $0, there's a reason — either the scope is too restrictive in practice, the program doesn't prioritize response, or all the bugs have been found.

Programs with 90+ day response SLAs. HackerOne displays median time to first response, median time to triage, and median time to bounty. Programs with long response times create dead capital — your vulnerability sits unresolved while you can't disclose it or test similar vectors.

Programs where everything is marked "out of scope" except one endpoint. This isn't a bug bounty program; it's a performance. Move on.

The top 10 most popular programs. Google, Facebook, Apple: every researcher on the planet targets them. Every easy vulnerability was found years ago. Finding something valid requires exceptional skill and significant time investment. Not the right starting point.

What to Target

Programs with wildcard scope (*.example.com, *.example-company.io). Wildcards mean more attack surface and more opportunity for something the security team hasn't had time to audit.

Recently launched programs or programs that have significantly expanded scope. New programs are a gold rush — the first wave of researchers hits them with recon tools and finds things fast. Follow program announcements on HackerOne's blog and Twitter/X.

Programs that pay for medium and low severities. A program that only pays for critical RCEs is not beginner-friendly. Programs with payout tables covering P3 and P4 findings signal that they want to improve overall security posture, not just avoid catastrophic breaches.

Programs in your area of technical expertise. If you've worked in fintech, target fintech companies. You understand the business logic, the likely attack surfaces, and what "impact" means to the business. Business logic vulnerabilities require domain knowledge that automated tools can't replace.

Recon Methodology: Building Attack Surface

Effective bug bounty hunting is 70% recon and 30% exploitation. The researchers making consistent income aren't spending all their time looking for vulnerabilities — they're spending most of their time finding attack surface that others haven't found yet.

Subdomain Enumeration

# Passive enumeration — no traffic to target
subfinder -d example.com -all -o passive_subs.txt
 
# Amass passive mode — pulls from additional sources
amass enum --passive -d example.com -o amass_passive.txt
 
# Certificate Transparency — every cert ever issued for the domain is logged
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u > ct_subs.txt
 
# Combine all passive sources
cat passive_subs.txt amass_passive.txt ct_subs.txt | sort -u > all_passive.txt
 
# Active DNS brute-force (only after confirming scope allows it)
puredns bruteforce /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt \
  example.com -r /path/to/resolvers.txt -o brute_subs.txt
 
# Permutation and pattern generation
gotator -sub all_passive.txt -perm permutations_list.txt -depth 1 -numbers 5 | \
  puredns resolve -r /path/to/resolvers.txt > permuted_subs.txt
 
# Merge everything
cat all_passive.txt brute_subs.txt permuted_subs.txt | sort -u > all_subs.txt

Probing for Live Hosts

# Probe for HTTP/HTTPS on standard and non-standard ports
httpx -l all_subs.txt \
  -ports 80,443,8080,8443,8888,9000,3000,5000,4000,7000,9090 \
  -status-code \
  -title \
  -tech-detect \
  -follow-redirects \
  -o live_hosts.txt
 
# Extract just the URLs
cat live_hosts.txt | cut -d ' ' -f1 > live_urls.txt

Content Discovery

# Directory and file discovery on live hosts
feroxbuster -u https://app.example.com \
  -w /usr/share/seclists/Discovery/Web-Content/raft-large-files.txt \
  -x php,asp,aspx,jsp,json,txt,bak,old,config,env \
  -t 50 \
  --depth 3 \
  -o ferox_output.txt
 
# ffuf with a status filter
ffuf -w /usr/share/seclists/Discovery/Web-Content/api-endpoints.txt \
  -u https://api.example.com/FUZZ \
  -mc 200,201,204,301,302,401,403 \
  -fc 404 \
  -t 40
 
# Google dorking to find exposed files
# site:example.com filetype:env
# site:example.com filetype:config
# site:example.com inurl:admin
# site:example.com "DB_PASSWORD"
# site:github.com "example.com" AND "password"

JavaScript File Analysis

JavaScript bundles are a goldmine: API endpoints, internal hostnames, authentication logic, feature flags, hardcoded secrets, and access control checks all live in frontend JavaScript.

# Crawl target and collect all JS files
katana -u https://app.example.com -jc -d 5 -o katana_output.txt
grep "\.js" katana_output.txt > js_files.txt
 
# Download and extract endpoints from JS files
cat js_files.txt | while read url; do
  curl -s "$url" | grep -oP '(?<=["\x27])/[a-zA-Z0-9_\-/]+(?=["\x27])' | sort -u
done | sort -u > js_endpoints.txt
 
# LinkFinder — more sophisticated endpoint extraction
python3 linkfinder.py -i https://app.example.com -d -o cli > linkfinder_results.txt
 
# SecretFinder — find credentials in JS
python3 SecretFinder.py -i https://app.example.com/main.js -o cli
# Looks for: API keys, tokens, passwords, AWS keys, Stripe keys, etc.

Automated Vulnerability Scanning

# Nuclei — template-based scanner covering thousands of vulnerability classes
nuclei -l live_urls.txt \
  -t ~/nuclei-templates/ \
  -severity medium,high,critical \
  -exclude-tags dos,fuzz \
  -rate-limit 50 \
  -o nuclei_findings.txt
 
# Target specific template categories
nuclei -l live_urls.txt -t ~/nuclei-templates/exposed-panels/ -o panels.txt
nuclei -l live_urls.txt -t ~/nuclei-templates/default-credentials/ -o default_creds.txt
nuclei -l live_urls.txt -t ~/nuclei-templates/cves/ -o cve_findings.txt
nuclei -l live_urls.txt -t ~/nuclei-templates/misconfiguration/ -o misconfigs.txt
nuclei -l live_urls.txt -t ~/nuclei-templates/technologies/ -o tech_detect.txt
 
# Specifically look for SSRF in webhook/URL-fetching features
nuclei -l live_urls.txt -t ~/nuclei-templates/vulnerabilities/generic/ssrf-via-* -o ssrf.txt

Vulnerability Hunting: High-Value Targets

IDOR (Insecure Direct Object Reference)

IDOR is consistently one of the highest-payout bug classes in bug bounty programs because it's difficult to find with automation and requires understanding the application's data model.

The pattern: an API endpoint takes an ID parameter (numeric, UUID, or other identifier) and returns or modifies the referenced resource without verifying that the authenticated user owns it.

# Testing methodology for IDOR:
# 1. Create two accounts (Account A and Account B)
# 2. With Account A: create a resource (order, invoice, message, etc.)
# 3. Note the resource ID in the API response
# 4. With Account B: attempt to access that resource ID
 
# Using Burp Suite Repeater:
# Capture a request as Account A
# Change the Authorization/Cookie header to Account B's session
# Observe whether Account B receives Account A's data
 
# Automated IDOR testing with a Burp Intruder setup:
# - Use Account A to generate 10 resource IDs
# - Replace session cookie with Account B's session
# - Intruder: Sniper mode, payload positions on the ID parameter
# - Payload: list of Account A's resource IDs
# - Grep match: Account A's unique identifiers in response

IDOR variants to test:

• GET resource (read) — lowest impact, but frequently accepted
• PATCH/PUT resource (modify) — higher impact
• DELETE resource — high impact
• GET list endpoint with another user's userId parameter
• Multi-layer IDOR: get organizationId from one endpoint, use it to access another user's org data
• UUID-based IDOR: UUIDs are hard to enumerate but can be predicted if created sequentially

OAuth and Authentication Flow Abuse

OAuth implementations frequently contain vulnerabilities that bypass authentication entirely or lead to account takeover.

# redirect_uri manipulation
# Original: redirect_uri=https://app.example.com/callback
# Attack 1: redirect_uri=https://attacker.com
# Attack 2: redirect_uri=https://app.example.com.attacker.com
# Attack 3: redirect_uri=https://app.example.com/../attacker.com
# Attack 4: redirect_uri=https://app.example.com/callback?x=attacker.com (if open redirect exists)
 
# state parameter CSRF
# If state parameter is missing or predictable, the OAuth flow is vulnerable to CSRF
# Test: initiate OAuth flow, capture the authorization URL
# Visit the URL from a different browser session — does the code still work?
 
# Token leakage in Referer header
# If the callback page loads third-party resources, the authorization code in the URL
# may leak via the Referer header to those third-party servers
 
# authorization code reuse
# After a successful OAuth flow, try reusing the same authorization code
# Should fail with "code already used" — if not, it's a finding

Host Header Injection

Many applications use the Host header to construct URLs for password reset emails, OAuth callbacks, and canonical links. A manipulable Host header can redirect password reset tokens to an attacker-controlled domain.

# Test for Host header injection in password reset
POST /forgot-password HTTP/1.1
Host: attacker.com
Content-Type: application/json
 
{"email": "[email protected]"}
 
# If the password reset email contains a link to attacker.com, it's a critical finding
# The victim clicks a "legitimate-looking" reset link that sends their token to the attacker
 
# Additional Host header tests:
# X-Forwarded-Host: attacker.com
# X-Host: attacker.com
# X-Forwarded-Server: attacker.com
# Forwarded: host=attacker.com

SSRF (Server-Side Request Forgery)

Cloud environments make SSRF critical. Any feature that fetches a user-supplied URL is a potential SSRF vector.

# Test webhook URL fields, URL preview features, PDF generation, image import
# Basic test payloads:
# http://169.254.169.254/latest/meta-data/ (AWS)
# http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS IAM creds)
# http://metadata.google.internal/computeMetadata/v1/ (GCP)
# http://169.254.169.254/metadata/v1/ (DigitalOcean)
# http://localhost:6379/ (Redis)
# http://localhost:9200/ (Elasticsearch)
# http://10.0.0.1/ (internal network discovery)
# file:///etc/passwd (local file access — if scheme allows)
 
# Use Burp Collaborator or interactsh for blind SSRF detection
# If the server makes any DNS or HTTP request to your OAST server, SSRF is confirmed
interactsh-client &
# Use generated domain in payload: http://your-unique-id.oast.fun/
 
# Tools
# ssrf-sheriff — purpose-built SSRF testing tool
# ffuf with SSRF payloads list from PayloadsAllTheThings

Account Takeover via Password Reset

# Password reset token entropy test
# Request 10 reset tokens for the same account
# Compare: are they random? Sequential? Time-based? Predictable?
 
# Host header injection (see above)
 
# Response manipulation: does the server validate the token server-side?
# 1. Request a password reset for [email protected]
# 2. Intercept the reset request validation
# 3. Modify the response: change "valid": false to "valid": true
# If this works, the client trusts the server response without server-side enforcement
 
# Token in URL shared via Referer
# Complete a password reset
# Note if the reset URL contains the token
# Check if the reset page loads any third-party resources (analytics, fonts, images)
# Burp: look at the Referer header sent to those third-party servers
# If the Referer contains the reset token, it was leaked
 
# Weak token format — 6-digit numeric with no rate limiting (Instagram 2019 bug)
# If you can make 1,000,000 requests and there's no lockout, all tokens are enumerable

Writing Reports That Get Paid

A valid vulnerability with a bad report gets marked informational, triaged as low, or duplicated out. The report is the product.

Report Structure

# IDOR on /api/v2/invoices/{id} allows read access to arbitrary user invoices
 
## Summary
An Insecure Direct Object Reference (IDOR) vulnerability on the invoice retrieval endpoint
allows any authenticated user to read invoices belonging to other users by manipulating
the `id` path parameter. No ownership verification is performed server-side.
 
## Severity
High (CVSS 3.1 score: 7.5 — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
 
## Steps to Reproduce
1. Create Account A ([email protected]) and Account B ([email protected])
2. With Account B, create an invoice. Note the invoice ID returned in the response:
   `{"id": 10042, "amount": 5000, "status": "pending"}`
3. Log into Account A and capture a valid session token.
4. Send the following request as Account A:
 
   GET /api/v2/invoices/10042 HTTP/1.1
   Host: app.example.com
   Authorization: Bearer <Account_A_token>
 
5. The server returns Account B's invoice data:
   {"id": 10042, "userId": "uuid-of-account-b", "amount": 5000, "status": "pending", "recipient": "Client Corp"}
 
## Impact
An authenticated attacker can read the contents of any invoice in the system by iterating
the numeric `id` parameter. This exposes invoice amounts, client names, contact information,
and payment status for every user. By iterating IDs 1 through N, an attacker can exfiltrate
the entire invoice database. Estimated records exposed: [check by requesting /api/v2/invoices/count].
 
## Proof of Concept
[Attach: screenshot of Burp request/response showing the cross-user data access]
[Attach: curl command showing reproduction]
 
curl -s -H "Authorization: Bearer ACCOUNT_A_TOKEN" \
  https://app.example.com/api/v2/invoices/10042 | jq .userId
# Returns Account B's userId — confirms cross-account access
 
## Remediation
Add an ownership check to the invoice retrieval query:
```sql
SELECT * FROM invoices WHERE id = $1 AND user_id = $2

Pass the authenticated user's ID as the second parameter. Return HTTP 403 if no record is found.

References

• OWASP A01:2021 – Broken Access Control
• CWE-639: Authorization Bypass Through User-Controlled Key

### Common Report Mistakes

**Missing reproduction steps.** The triager should be able to reproduce your finding in under five minutes without asking you anything. If your steps require assumptions or context they don't have, your report stalls.

**Overstated severity.** A missing security header rated as Critical, or a rate-limiting gap on a non-sensitive endpoint rated as High — triagers see this constantly. It signals inexperience and damages your credibility. Use CVSS and justify it. If a finding requires significant user interaction or specific conditions, the severity goes down.

**No demonstrated impact.** "This could lead to data exposure" is not impact. "An unauthenticated attacker can read all user invoices by iterating the numeric id parameter from 1 to N, exposing names, email addresses, billing addresses, and payment amounts for all X users" is impact.

**Reporting missing headers as High/Critical.** Missing `Content-Security-Policy`, `X-Frame-Options`, or `X-Content-Type-Options` without a demonstrated impact gets marked Informational. These findings have value only when combined with an actual exploitation scenario.

**Self-XSS.** If the payload only executes in your own session, it's not a valid XSS submission. The attack must affect a different user.

**Chasing version numbers.** "The server is running Apache 2.4.49, which is vulnerable to CVE-2021-41773" is only valid if you can demonstrate the actual exploit works in this environment. Version disclosure + CVE ≠ validated finding.

---

## Building a Recon Pipeline

Manual recon is slow. Researchers making consistent income have automated the commodity work so they can focus on the manual analysis that differentiates findings.

```bash
#!/bin/bash
# Simple recon automation script — runs on a new target domain

TARGET=$1
OUTPUT_DIR="recon-$TARGET-$(date +%Y%m%d)"
mkdir -p "$OUTPUT_DIR"

echo "[+] Starting passive subdomain enumeration for $TARGET"
subfinder -d "$TARGET" -all -silent -o "$OUTPUT_DIR/subs_passive.txt"
amass enum --passive -d "$TARGET" -o "$OUTPUT_DIR/subs_amass.txt"
curl -s "https://crt.sh/?q=%.${TARGET}&output=json" | \
  jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u > "$OUTPUT_DIR/subs_ct.txt"

echo "[+] Merging and resolving subdomains"
cat "$OUTPUT_DIR"/subs_*.txt | sort -u | \
  puredns resolve -r ~/resolvers.txt > "$OUTPUT_DIR/resolved_subs.txt"

echo "[+] Probing for live hosts"
httpx -l "$OUTPUT_DIR/resolved_subs.txt" \
  -ports 80,443,8080,8443,3000,5000 \
  -status-code -title -tech-detect \
  -o "$OUTPUT_DIR/live_hosts.txt"

cat "$OUTPUT_DIR/live_hosts.txt" | cut -d ' ' -f1 > "$OUTPUT_DIR/live_urls.txt"

echo "[+] Running nuclei scans"
nuclei -l "$OUTPUT_DIR/live_urls.txt" \
  -t ~/nuclei-templates/ \
  -severity medium,high,critical \
  -exclude-tags dos \
  -o "$OUTPUT_DIR/nuclei_results.txt"

echo "[+] Crawling for endpoints and JS files"
katana -list "$OUTPUT_DIR/live_urls.txt" -d 3 -jc -o "$OUTPUT_DIR/katana_output.txt"

echo "[+] Done. Results in $OUTPUT_DIR/"

Realistic Financial Expectations

The bug bounty economics are worth being honest about:

Median payout per valid finding: $400-$800 (P3 Medium severity)

High severity (P2) typical range: $2,000-$10,000

Critical severity (P1) typical range: $5,000-$100,000+

All-time record payouts (public data):

• Apple Security Research Device Program: $300,000 (iOS zero-click)
• Google VRP: $605,000 (combined chain across multiple bugs, 2022)
• Samsung Mobile Security: $1,000,000 (theoretical maximum; first claimed in 2023)

Time reality: Expect to spend 20-40 hours before your first valid finding. Most researchers report 3-6 months before making meaningful income. The researchers consistently earning $100,000+/year have typically been doing this for 3+ years.

What top earners have in common:

• Narrow specialization in 1-2 vulnerability classes where they have deep expertise
• Proprietary automation built on top of commodity tools
• Focus on specific industry verticals where they understand business logic
• Reputation high enough to access premium private programs
• Systematic documentation of every target tested and methodology applied

The $200/hour fantasy from YouTube is real for a small number of experienced researchers. The realistic starting expectation is closer to minimum wage per hour — until your skill and reputation compound.

Legal and Ethical Boundaries

The rules are simple and absolute:
1. Read the program scope before sending a single request to any target
2. Test only assets explicitly listed in scope
3. Do not access, modify, or exfiltrate real user data — stop at proof of concept
4. Report what you find, don't exploit it further
5. If scope is ambiguous, ask before testing

Out-of-scope testing gets you permanently banned from the platform and can expose you to legal liability under the Computer Fraud and Abuse Act (US), Computer Misuse Act (UK), and equivalent statutes in other jurisdictions. Safe harbor language in bug bounty policies only protects you when you stay within scope and follow responsible disclosure rules.

A common gray area: you find an asset that looks like it belongs to the target company but isn't explicitly listed in scope. Don't test it. Message the program, ask if it's in scope, and wait for a response. This approach has led to scope expansions and bonus payments for researchers who've found critical bugs on previously out-of-scope assets — the right way.

Getting Started: Week-by-Week

Week 1-2: Complete PortSwigger Web Security Academy's learning paths for SQL Injection, XSS, CSRF, and Authentication. Do every lab. Understand the mechanics, not just the payloads. If you want a structured credential to anchor this learning, our roundup of security certs worth getting covers the web-focused options like BSCP.

Week 3-4: Set up your tools environment — Kali Linux VM, Burp Suite Community, Subfinder, httpx, nuclei, ffuf, katana. Run through the setup guide for each tool.

Week 5-6: Choose a public program on HackerOne with wildcard scope and medium severity payouts. Run your recon pipeline. Read every disclosed report for that program. Don't submit yet — just learn the target's architecture.

Week 7-8: Start testing manually. Focus on a single vulnerability class — IDOR is recommended for beginners because it requires no special tools, the methodology is learnable, and the payouts are consistent. Find 20 API endpoints and test every resource parameter for cross-user access.

Week 9+: Your first report. Make it a clear, technically accurate, well-documented submission. Then iterate. Track every submission, whether valid or not, and analyze what you're missing.

The researchers who make it are systematic, patient, and rigorous. They treat it like a craft rather than a lottery. If you approach it the same way, the results follow.

How Bug Bounty Programs Evolved

Paying outsiders to find security flaws predates the modern platform economy. Netscape ran a "Bugs Bounty" for its Navigator browser in 1995, offering cash for vulnerabilities in beta releases. For most of the next decade the practice stayed rare, because companies had no structured way to receive reports, verify them, or pay strangers safely. A researcher who found a flaw often had two poor options. Stay silent, or email a security contact who might respond with a legal threat instead of gratitude.

Two shifts changed that. Google and Mozilla launched formal reward programs around 2010 with published scopes, severity tables, and predictable payouts. That signaled to the wider industry that structured disclosure was cheaper than the alternative of being breached. Then HackerOne and Bugcrowd, both founded in 2012, built the plumbing: a place to submit reports, a reputation system, a payment rail, and safe harbor language that gave researchers legal cover. Once the transaction cost of running a program dropped, thousands of companies could participate without building the machinery themselves.

The maturation created the current reality. Popular programs are heavily contested, automated recon is a commodity, and the easy findings on well known targets disappear within hours of a scope change. This is why program selection and specialization matter more now than raw tool knowledge. The tools are the same ones everyone has. Your edge comes from where you point them and what you understand that the scanner does not.

Vulnerability Classes Compared

Different bug classes reward different amounts of effort. Some are found by scanners in seconds and are therefore duplicated constantly. Others resist automation and reward patient manual analysis. The table below maps common classes by how easily a scanner finds them, the typical severity band, and how much competition you should expect.

Read the pattern from this table. The classes with low scanner-findability and low competition (SSRF, business logic, IDOR) are where sustained income lives, because they require understanding the application instead of running a template. Subdomain takeover and open redirect are trivial to find, which means everyone finds them, which produces duplicates and low payouts. Beginners often start on the easy-to-find classes and grow frustrated by the duplicate rate. Moving one notch harder, into IDOR and access control, usually improves results faster than any new tool.

What Happens After You Submit

Understanding the triage pipeline changes how you write reports. When you submit, the report usually lands with a platform triage analyst or the program's own security team. Their first job is to reproduce your finding. If they cannot reproduce it in a few minutes using only what you provided, the report moves to a "need more information" state, and every hour it sits there is an hour a duplicate can be filed by someone else.

Once reproduced, the report gets a state and a severity. Common states include triaged (accepted, awaiting a fix), duplicate (someone reported it first), informational (real but not rewarded), and not applicable (out of scope or not a security issue). Severity is usually assigned with CVSS or the program's own rating. This is where an overstated severity costs you. If you claim critical and the triager downgrades it to medium, you have spent credibility for nothing.

Payment timing varies. Some programs pay on triage, before the fix ships. Others pay on resolution, after their engineers deploy a patch, which can take weeks or months. A program's median time-to-bounty statistic, shown on its page, tells you how long your capital will sit locked up. This is a real cost for full-time hunters and a reason to weight fast-paying programs when you depend on the income.

Duplicates are the most demoralizing outcome and the least avoidable. If two researchers find the same bug, the first valid submission wins and the second earns nothing, regardless of report quality. This is why speed on a freshly launched or freshly expanded scope matters, and why hunting a well-worn target with commodity tools is a losing strategy. Any bug a public template finds has almost certainly been found already.

Detection Signals a Program Is Worth Your Time

Before committing recon hours, read these signals off the program page. A published payout table that covers P3 and P4 findings, rather than P1 and P2 alone, shows the program values medium and low severities. A median time-to-first-response under a few days means less locked capital and lower duplicate risk. Recent scope additions or a recently raised bounty table point to un-audited surface. A high ratio of resolved reports to submitted reports shows the team acts on findings. Disclosed reports you can read give you free intelligence on what the program accepts and how it rates severity.

The inverse signals warn you off. Two years live with zero bounties paid, everything marked out of scope except one login page, or a response window measured in months. Each of these turns your time into dead capital. Spending an hour reading the program page before you start saves days of misdirected effort.

Frequently Asked Questions

Do I need a formal computer science degree to earn bounties? No. Programs pay for valid findings regardless of credentials. What you need is demonstrable skill in a vulnerability class and the discipline to write a reproducible report. Many consistent earners are self-taught. A degree helps for salaried application security roles, less so for independent bounty income.

Is it legal to run recon tools against a company that has no program? Treat the absence of a program as a no. Scanning, brute-forcing, or fuzzing a target without authorization can violate the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act in the United Kingdom, and similar laws elsewhere. Safe harbor exists only inside a published program scope. If a company has a security.txt file or a vulnerability disclosure policy, follow it exactly.

How do I reduce the number of duplicates I submit? Target fresh scope, read disclosed reports to see what has already been found, and go deeper than the surface findings a scanner produces. A bug that required understanding the application's data model is far less likely to collide than a missing security header that a template flags on every host.

Why was my valid bug marked informational? Informational usually means the finding is real but carries no demonstrated security impact the program is willing to pay for. Missing security headers, verbose version banners, and self-XSS are the classic examples. The remedy is to either demonstrate concrete impact or move on to classes that carry weight.

Should I use automated scanners or hunt manually? Both, in sequence. Run scanners to inventory the attack surface and catch commodity issues quickly, then spend your hours on the manual analysis that scanners cannot do: access control logic, business rules, and chained vulnerabilities. The money is in the manual work because that is the work most people skip.

How long before I make my first valid submission? Plan for twenty to forty hours of focused work before your first accepted finding, and three to six months before income is meaningful. The researchers who quit almost always quit in the first month, before the learning compounds.

Can I do bug bounty part-time alongside a job? Yes, and most people start that way. Part-time hunting rewards a narrow focus. Pick one program and one vulnerability class, run a scheduled recon pipeline, and check for new surface weekly. Depth on a single target beats shallow sweeps across many.

Related guides

• OWASP Top 10 Explained
• OSINT Reconnaissance
• SQL Injection Explained
• Cross-Site Scripting (XSS)
• How to Become an Ethical Hacker