Bug bounty hunting is one of the most accessible and genuinely rewarding ways to start a career in cybersecurity. You do not need a degree, a certification, or an employer — you need a laptop, an internet connection, the right knowledge, and patience. Companies including Google, Meta, Microsoft, Apple, and thousands of others will pay you real money to find vulnerabilities in their systems. In 2025, HackerOne alone paid out over $300 million in total bounties since its inception, with individual researchers earning six and seven-figure annual incomes.
The barrier is not access — it is knowing where to start. Most beginners fail not because they lack talent, but because they start on the wrong programmes, look for the wrong vulnerabilities, and do not know how to write a report that gets paid. This guide fixes all three problems. It covers everything you need to find your first vulnerability and get your first bounty — platform selection, the right mindset, the eight vulnerability types beginners actually find, a full recon methodology, a complete report template, and a 90-day roadmap from zero to first payout.
- What is bug bounty hunting — and how does it actually work?
- Bug bounty platforms — HackerOne vs Bugcrowd vs Intigriti vs self-hosted
- How to choose your first programme — the most important decision
- The beginner's mindset — why most people fail and how to avoid it
- The 8 vulnerability types beginners actually find and get paid for
- Reconnaissance methodology — mapping the attack surface
- Essential tools — your starter kit
- Finding vulnerabilities — a practical step-by-step workflow
- Writing a winning report — the template that gets paid
- Understanding bounty amounts — what pays what and why
- 90-day roadmap — from zero to first bounty
- Frequently asked questions
A bug bounty programme is a formal agreement in which a company invites security researchers to test its systems for vulnerabilities and pays cash rewards for valid findings. The company defines what can be tested (the scope), what types of vulnerabilities qualify (the rules), and how much different finding severities pay (the bounty table).
As a bug bounty hunter, you sign up to a programme, read its scope and rules, test the permitted systems for vulnerabilities, and submit a report when you find one. If the company's security team validates your finding as genuine and in-scope, they pay you the bounty. The entire process is legal, structured, and mutually beneficial — the company gets security research it could never buy internally, and you get paid for knowledge that would otherwise sit unused.
| Severity | CVSS range | Typical bounty (major programme) | Typical bounty (smaller programme) |
|---|---|---|---|
| Informational / Low | 0.1–3.9 | $50–$200 or no payout | Hall of fame / swag only |
| Medium | 4.0–6.9 | $200–$2,000 | $100–$500 |
| High | 7.0–8.9 | $2,000–$10,000 | $500–$3,000 |
| Critical | 9.0–10.0 | $10,000–$150,000+ | $2,000–$20,000 |
| Platform | Programmes | Beginner-friendly | Best for | Sign up |
|---|---|---|---|---|
| HackerOne | 3,000+ | ⭐⭐⭐⭐⭐ — large public programmes, good docs | Largest selection, best learning resources, top companies | hackerone.com |
| Bugcrowd | 1,500+ | ⭐⭐⭐⭐ — good onboarding, researcher ratings | US government programmes, fintech, healthcare | bugcrowd.com |
| Intigriti | 800+ | ⭐⭐⭐⭐ — strong European programme selection | European companies, GDPR-focused programmes | intigriti.com |
| Yeswehack | 500+ | ⭐⭐⭐ — growing platform | French/European companies, automotive sector | yeswehack.com |
| Synack Red Team | Invite-only | ⭐⭐ — requires vetting | High-value exclusive programmes, guaranteed pay | synack.com |
| Direct / self-hosted | Varies | ⭐⭐⭐ — read programme rules carefully | Major tech companies: Google VRP, Microsoft MSRC, Apple Security | Individual company pages |
Most beginners make the same mistake: they pick a major tech company's programme (Google, Meta, Apple) because of the large bounties, spend weeks finding nothing, and conclude bug bounty hunting is too hard. The problem is not their skills — it is that those programmes have thousands of experienced researchers who have already found most of the accessible bugs. You are competing at the wrong level.
The right approach is to choose programmes where the competition is lower and the attack surface has not been exhaustively tested. Here is exactly how to filter for this:
Most beginners approach bug bounty hunting like a video game: they expect a clear path, obvious vulnerabilities, and regular rewards for effort. Bug bounty hunting is more like prospecting for gold — long stretches of nothing, then unexpected finds. The researchers who succeed are the ones who develop these habits:
- Test one programme deeply, not ten programmes shallowly. Pick one target and learn it thoroughly — its authentication system, its API, its data model, how it handles permissions. Surface-level scanning of many programmes produces nothing. Deep understanding of one produces findings.
- Think like a user who is also an attacker. Use the application the way a real user would, but constantly ask: what happens if I change this parameter? What if I use this feature in a way it was not designed for? What data is this endpoint returning that it probably should not?
- Read other researchers' writeups every day. The HackerOne Hacktivity feed and Bugcrowd Crowdstream are goldmines. When a researcher discloses a finding, read the writeup carefully — understand the vulnerability class, how they found it, what made it pay. After reading 100 writeups, you will recognise those patterns in the wild.
- Document everything, even failed attempts. Keep notes on every endpoint tested, every parameter manipulated, every thing tried and ruled out. This prevents testing the same things twice and sometimes reveals patterns only visible in retrospect.
- Duplicates are not failures — they are confirmation of good instincts. Getting a duplicate means you found a real vulnerability that someone else found first. That is proof your methodology works. Adjust your timing (newer programmes, newer features) rather than your approach.
Beginners often focus on the dramatic vulnerabilities — RCE, SQLi, authentication bypass — that make headlines. These exist and pay extremely well, but they are also the first things experienced hunters look for and have often already been found. The vulnerabilities below are what beginners realistically find on their first programmes, are consistently in scope, and pay meaningful bounties.
Insecure Direct Object Reference — accessing another user's data by changing an ID in a URL or request body. Example: changing /api/invoice/1234 to /api/invoice/1235 and seeing another user's invoice. One of the most commonly found beginner bugs.
Accessing functionality you should not have access to — admin panels, other users' settings, privileged API endpoints. Example: a regular user who can access /admin/users by navigating directly to the URL.
Cross-Site Scripting — injecting JavaScript into a page that runs in another user's browser. Stored XSS (persists in the database) pays far more than reflected. Look for user-controllable text that appears in other users' views.
Password reset flaws, predictable tokens, MFA bypass, username enumeration. Example: a password reset link that uses a predictable timestamp-based token instead of a cryptographically random one. Very common in smaller programmes.
API keys, credentials, internal paths, stack traces, or PII exposed in responses, JavaScript files, or error messages. Check JS source files on the target — developers frequently commit API keys. Tools like LinkFinder and SecretFinder automate this.
Cross-Site Request Forgery — tricking a logged-in user into performing an unintended action. Less common now that SameSite cookies are widespread, but still found on older codebases and sensitive actions like changing email, deleting accounts, or modifying payment details.
A subdomain points to a third-party service (GitHub Pages, Heroku, S3 bucket) that no longer has a record matching that subdomain. You can claim the service yourself and serve content under the company's subdomain. Automated discovery tools find these efficiently.
APIs often expose more data than needed, lack rate limiting, have missing authentication on certain endpoints, or accept parameters that the UI does not expose. Intercepting mobile app traffic with Burp Suite is the most reliable way to find API endpoints that the web UI never calls.
Before you can find vulnerabilities, you need to know what is there to test. Reconnaissance is the process of mapping every asset in the programme's scope — subdomains, endpoints, parameters, technologies, and functionality — so you can make informed decisions about where to focus.
| Tool | Purpose | Cost | Priority |
|---|---|---|---|
| Burp Suite Community | Intercept, modify, and replay HTTP requests. The single most important bug bounty tool. | Free | 🔴 Essential — install first |
| subfinder | Subdomain enumeration — finds subdomains passively from multiple sources | Free | 🔴 Essential |
| httpx | Probes a list of subdomains/URLs to find which are live, their status codes and titles | Free | 🔴 Essential |
| ffuf | Fast web fuzzer for directory/file discovery and parameter fuzzing | Free | 🔴 Essential |
| Nuclei | Automated vulnerability scanning with 9,000+ templates | Free | 🟡 Important |
| katana | Web crawler that discovers JS files, API endpoints, and forms | Free | 🟡 Important |
| gau / waybackurls | Fetches historical URLs from Wayback Machine and other archives — finds forgotten endpoints | Free | 🟡 Important |
| SecretFinder / TruffleHog | Finds API keys and secrets in JS files and GitHub repositories | Free | 🟡 Important |
| amass | Comprehensive subdomain discovery — more thorough than subfinder but slower | Free | 🟢 Useful |
| Burp Suite Pro | Automated scanner, advanced intruder, collaborator (SSRF/blind XSS detection) | $449/year | 🟢 Upgrade later |
IDOR is the best vulnerability class for beginners to start with. Here is the exact workflow to find it:
A good vulnerability report is the difference between getting paid and getting marked "informative" or "not applicable." Triage engineers read hundreds of reports — a clear, complete, well-structured report gets validated faster, gets paid at the higher end of the bounty range, and builds your reputation on the platform. A vague report with missing reproduction steps gets closed.
Bounty amounts are not arbitrary — they follow a logic based on impact, exploitability, and programme budget. Understanding this logic helps you write reports that are assessed at the severity level your finding deserves.
- Impact is the primary driver. What can an attacker do with this vulnerability? View data = lower impact. Modify or delete data = higher impact. Exfiltrate all users' data = critical. Impact on the company's core business (payments, authentication, admin functions) pays more than impact on peripheral features.
- Exploitability affects severity. A vulnerability requiring no authentication, no user interaction, and affecting all users pays more than one requiring a specific user role, complex prerequisites, or social engineering. The CVSS Attack Vector, Complexity, and Privileges Required metrics formalise this.
- Report quality influences the outcome. A finding reported with clear reproduction steps, accurate severity assessment, and professional writing is more likely to be validated quickly and paid at the higher end of the bounty range than the same finding reported vaguely.
- Programme budget and policy matter. Some programmes cap bounties at specific amounts regardless of severity. Others award above-table amounts for exceptional findings. Read the programme policy before submitting — knowing the maximum payout for each severity level helps you calibrate expectations.
- Install Kali Linux (or set up Burp Suite on your existing OS) and configure the proxy
- Complete the PortSwigger Web Security Academy labs — specifically: SQL injection, XSS, IDOR, access control, and authentication. All free at portswigger.net/web-security. This is the single best free resource for learning web vulnerabilities with hands-on labs.
- Create accounts on HackerOne and Bugcrowd — explore the platform, read 20 disclosed reports from the Hacktivity feed
- Install subfinder, httpx, ffuf, and katana
- Choose your first programme using the criteria in Section 3 — read its entire scope and rules document carefully
- Run your first recon on the chosen programme — subdomains, live hosts, content discovery
- Create two test accounts on your chosen programme and begin systematic IDOR testing using the workflow in Section 8
- Spend at least 2 hours per day on the same programme — depth over breadth
- Scan JS files for exposed secrets and API endpoints; check for subdomain takeover candidates
- Read one publicly disclosed report from your programme (or similar) every day — understand what findings look like on this specific target
- Test every new feature the company releases — follow their changelog and blog
- If you find a potential finding: reproduce it three times, confirm it is in scope, and write the report using the template in Section 9
- Submit your first report — even if you are not 100% sure it is valid. A good-faith report that turns out to be a duplicate or informational is still a learning experience and builds platform history.
- Review all feedback from your submitted reports — understand why each was marked valid, duplicate, or informational
- Expand to a second programme with similar characteristics to your first
- Add Nuclei to your workflow for automated CVE and misconfiguration scanning
- Learn one new vulnerability class beyond IDOR — choose the one most relevant to your target's technology stack (XSS for content platforms, auth issues for SaaS, API flaws for mobile-heavy apps)
- Apply for private programme invitations on HackerOne — your submission history qualifies you for programmes with less competition and better payouts
- If no bounty yet: do not give up. Review your reports with fresh eyes, ask for feedback in the HOC Discord or similar community, and identify whether the issue is scope selection, methodology, or reporting quality
⚡ Start your bug bounty journey today
- Create a HackerOne account right now — it takes 5 minutes. Browse the programme directory, sort by "Newest", read the scope of three programmes that look interesting. hackerone.com
- Do the PortSwigger Web Security Academy — the free IDOR, access control, and authentication labs teach the vulnerability classes you will actually find. portswigger.net/web-security. Aim to complete 30 labs in your first month.
- Set up Burp Suite Community Edition — the most important tool in your kit. Burp Suite tutorial →
- Understand the broader pentesting methodology — bug bounty hunting shares structure with professional penetration testing. Understanding the full methodology gives you a systematic approach. What is penetration testing? →
- Add AI tools to your toolkit — tools like Nuclei AI and BurpGPT give beginners leverage that was not available three years ago. Top 10 AI security tools →
- Learn network reconnaissance — Nmap is essential for understanding the attack surface of any target. Nmap tutorial →
No. Bug bounty programmes pay based on findings, not credentials. Many of the top earners on HackerOne and Bugcrowd have no formal security qualifications. What you need is practical knowledge of how web applications work, how vulnerabilities arise, and how to test for them — all of which can be learned for free through PortSwigger Web Security Academy, TryHackMe, HackTheBox, and reading public vulnerability disclosures. Certifications like eJPT or OSCP are useful for a security career but not required for bug bounty payouts.
Most focused beginners who follow a structured approach (right programme selection, systematic methodology, daily practice) find their first valid finding within 60–120 days. The key variables are: how much time you dedicate daily (2+ hours accelerates significantly), whether you choose beginner-appropriate programmes, and whether you learn from each submission's feedback. Researchers who jump between programmes constantly and spend less than an hour a day typically take much longer or give up first.
Public programmes are open to any registered researcher on the platform — anyone can find and submit reports. Private programmes are invitation-only — the company selects specific researchers based on their platform reputation, finding history, and specialisation. Private programmes typically pay better, have less competition, and receive more responsive triage. You earn invitations to private programmes by building a submission history on public programmes, maintaining a strong signal-to-noise ratio (valid reports vs invalid/informational), and specialising in relevant vulnerability classes.
A duplicate report means someone else already found and reported the same vulnerability. It is the most common disappointment for beginners. You still do not get paid for duplicates (on most programmes), but it confirms your methodology is working. To reduce duplicates: focus on newer programmes with less competition, specifically test new features immediately when they launch, look at less-obvious areas of the application that experienced hunters skip (mobile APIs, admin flows, file upload handling), and develop specialisation in vulnerability classes that are harder to find with automated tools.
Yes — bug bounty researchers earn bounties from almost every country. HackerOne and Bugcrowd support international payments via PayPal, bank transfer, and cryptocurrency. Some US government programmes (DoD, CISA) require researchers to be US citizens or pass identity verification. Tax treatment of bounty income varies by country — treat it as freelance income and consult a local tax professional if your earnings become significant.
IDOR (Insecure Direct Object Reference) is universally recommended for beginners. It requires minimal tooling, the testing methodology is straightforward (two accounts, substitute one ID for another), and it is consistently found in new and growing applications because it is an architectural flaw that automated scanners miss. After IDOR, broken access control (accessing functionality you should not have) and information disclosure (API keys, credentials, excessive data in API responses) are the next most commonly found by beginners.
Stop testing immediately. Do not further investigate or exploit the vulnerability. Report it to the company's security team via their disclosure email (usually security@company.com) with a note that you found it while working on their bug bounty programme but recognise it is out of scope. Most companies appreciate responsible disclosure even for out-of-scope findings and may create a special case or adjust their scope. Do not submit it to the bug bounty platform as an in-scope finding — misrepresenting scope is grounds for banning from the programme.
