Safety Center
Bug Bounty for Beginners: A Legal-First Guide
Bug bounty hunting rewards people who find security weaknesses in systems whose owners invite them to look. This guide gives you the legal-first path: learn the rules before you touch anything, practise in labs, read disclosed reports, and only then hunt in scope.
What bug bounty hunting is — and is not
Bug bounty hunting means finding security weaknesses in websites, apps or systems whose owners have publicly invited testing, and reporting them through the programme's official channel in exchange for a reward or recognition. The owner defines what you may test (the scope), what techniques are allowed, what is out of bounds, and how to report. You find a weakness, you prove it carefully, you report it privately, and the owner fixes it.
What it is not: it is not hacking random websites 'to help', it is not a quick income stream, and it is not a replacement for learning fundamentals. The strongest beginner guides all say the same thing in different ways: the hunters who last are the ones who learned the rules and the fundamentals first, and treated the first months as education.
The law comes first — read this before anything else
The single most important rule: testing outside a programme's scope is still unlawful in many countries even if you report the bug afterwards. The scope page is the law of that programme. Never test a system without an invitation, written permission, or a public programme that covers it. This applies to every technique on this page.
The legal frame differs by country — computer-misuse laws in the UK, the Computer Fraud and Abuse Act in the US, and equivalents elsewhere — but the principle is the same everywhere: authorisation decides legality, not intention. A good report does not retroactively authorise an unauthorised test. Keep records of every programme you join, the scope as it stood when you tested, and every report you file. If a programme's rules are unclear, ask the programme owner before testing, not after.
The staged path: foundations, labs, reports, then hunting
- Stage 1 — Foundations (weeks 1–6). Learn how the web works: HTTP, cookies, sessions, authentication, how browsers and servers talk. Learn the common weakness classes at concept level — cross-site scripting (XSS), SQL injection, insecure direct object references (IDOR), server-side request forgery (SSRF) — as vocabulary, not as recipes. Free, legal practice platforms are the place to learn them.
- Stage 2 — Labs (weeks 4–12, overlapping). Practise in free, legal labs: PortSwigger Web Security Academy and Hacker101 are the standard starting points, alongside hands-on platforms such as TryHackMe and HackTheBox. In labs you may experiment freely, break things, and learn how weaknesses actually behave — because the lab is yours to break.
- Stage 3 — Read disclosed reports (two weeks). Before you hunt, read disclosed reports on HackerOne and similar platforms. Study how good reports are written: clear title, reproduction steps anyone can follow, evidence, and honest impact. Notice also which reports were rejected and why — duplicate, out of scope, or not actually a vulnerability. A crash, by itself, is not a vulnerability; impact must be shown.
- Stage 4 — Vulnerability disclosure programmes. File your first reports through VDPs: programmes that invite reports without paying bounties. The stakes are lower, the feedback is real, and you learn the reporting process safely.
- Stage 5 — Paid programmes. Only now move to paid programmes, starting with wide-scope, beginner-friendly ones with clear rules and fast triage. Pick one programme and learn it deeply rather than skimming twenty.
At every stage, keep a learning log: what you tried, what you learned, which reports you read and what made them good. That log becomes your portfolio and your interview material.
Scopes and rules: how to read them
Every programme publishes a scope page: the domains, apps and assets you may test, the techniques that are allowed, and the things that are explicitly out of scope — often including denial-of-service testing, social engineering, physical attacks, and testing third-party services. Reading a scope page properly is a skill in itself, and our companion guide How to Read a Bug Bounty Scope Page works through a real public programme as an example.
The habits that keep you safe: read the whole scope page before testing anything; note the date, because scopes change; stay inside the listed assets; use only allowed techniques; stop and ask if anything is unclear; and never test an asset that is not listed, even if it belongs to the same company. If you find a weakness in an out-of-scope asset, do not test it further — report the existence of the finding through the proper channel and let the owner decide.
Your first vulnerabilities: where beginners actually find them
Beginners most often succeed with weaknesses that reward careful reading rather than advanced tooling: IDOR (changing an identifier to access another user's data — only inside an authorised programme), reflected cross-site scripting in search or feedback fields, open redirects, missing security headers where the programme counts them, and information disclosure in error messages or responses. More advanced classes — SQL injection, SSRF, authentication bypass — come later, after the fundamentals are solid.
Whatever you find, the report is the product. Use the structure in our vulnerability report template: title, asset, steps to reproduce, evidence, impact explained honestly, and suggested fix. A clear report for a medium weakness earns more respect — and more often a bounty — than a confused report for a severe one.
Honest economics: what to expect
Published earnings figures for bug bounty hunting conflict and are mostly unattributed, so this page does not repeat them as fact. What the serious beginner guides agree on is the shape of the outcome: most people who quit bug bounty quit in the first six months; most beginners earn nothing for the first three to six months; and the hunters who eventually earn consistently treat the early period as a learning investment, not income. Large payout totals reported by platforms describe the whole platform over years, not what a beginner can expect.
Plan accordingly: do not leave a job to hunt bounties, do not pay for expensive courses on the promise of bounty income, and measure your first six months in skills and accepted reports, not in money. If the money comes, it comes because the skill is real.
Tools, without the hype
Beginners need a small, honest toolkit: a web proxy for inspecting and modifying traffic in labs and authorised programmes, a browser with developer tools, and the standard reconnaissance tools used in authorised work — used only inside scope. Learn each tool's purpose before you learn its commands, and never run automated scanners against a programme asset unless the scope explicitly allows it. Aggressive scanning is one of the fastest ways to be banned from a programme.
Staying in the field
The hunters who last do three things: they specialise (one weakness class, one asset type, one programme at a time), they write excellent reports, and they stay inside the rules even when it costs them a finding. Reputation on the platforms matters: programme owners invite trusted hunters to private programmes with better scopes and rewards. That invitation is earned by a history of clean, in-scope, well-written reports — which is exactly what the staged path above builds.
Choosing a target: depth beats breadth
Beginners usually fail by spreading thin: a few hours on twenty programmes, finding nothing anywhere. The hunters who succeed do the opposite — they pick one programme, learn its application deeply, and stay there for weeks. Read its disclosed reports, map its features, understand its business logic, and test the places other hunters overlook: the forgotten settings page, the password-reset flow, the export function, the mobile app's older version. Depth is where beginner findings live, because the obvious endpoints have already been tested by hundreds of people.
Pick programmes with clear scopes, responsive triage, and a history of paying beginners fairly. Avoid programmes with vague scopes or a reputation for closing reports without explanation — the scope page and the disclosed reports will tell you both. And set a time limit: if a programme yields nothing after a focused month, switch, and take what you learned with you.
What triage looks like, and how to handle the wait
After you submit a report, the platform's triage team checks it: is it in scope, is it reproducible, is it a duplicate of an earlier report, and what is its severity? That takes days or weeks, and silence does not mean rejection. While you wait, do not re-test the same finding aggressively, do not discuss it publicly, and do not submit the same report to another programme. If the report is closed as a duplicate, read the feedback: duplicates are common, and they usually mean another hunter found the same weakness first — not that your work was bad. If it is closed as not applicable, study the reason, because it teaches the boundary of what counts as a vulnerability on that programme.
Staying safe and staying motivated
Set boundaries early. Hunt in fixed sessions rather than around the clock, keep a log of what you tried and what you learned, and celebrate accepted reports — including low-severity ones — because each one proves the process works. Avoid the forums and leaderboards when they make you feel behind: the public rankings show the top of a large field, not the typical experience. And keep the legal rule in view at all times: the scope page is the law of the programme, and a hunter with a clean record and a history of good reports is worth more — to programmes and to future employers — than a hunter with a bigger bounty total and a ban.
Sources
- HackerOne — disclosed reports and programme directory
- PortSwigger Web Security Academy — free legal web security labs
- CERT Guide to Coordinated Vulnerability Disclosure
- Research methodology — how this guide was researched
Frequently asked questions
Is bug bounty hunting legal?
Yes — when you stay inside a programme's scope and rules. Testing outside scope is still unlawful in many countries even if you report the bug afterwards. The scope page is the law of that programme: read it fully before testing anything.
How do I start bug bounty hunting with no experience?
Learn web fundamentals, practise in free legal labs, read disclosed reports for two weeks, then start with vulnerability disclosure programmes (VDPs) — which invite reports without paying bounties — before moving to paid programmes.
Which bug bounty platform is best for beginners?
The two largest are HackerOne and Bugcrowd. Both host programmes with defined scopes and rules, plus disclosed reports you can learn from. Start by reading reports and VDPs rather than by chasing the highest bounties.
How much can a beginner earn from bug bounties?
Most beginners earn nothing for the first months, and that is normal. This site does not repeat earnings figures as fact because published figures conflict and are mostly unattributed. Treat bug bounty as a learning investment first and income second — see the honest economics section below.
Do I need a security degree to start bug bounty hunting?
No. Platforms and programme owners care about the quality of your reports: clear reproduction steps, evidence, and impact explained honestly. A degree is not required.
What is the difference between a VDP and a bug bounty programme?
A vulnerability disclosure programme (VDP) invites you to report weaknesses but does not pay bounties; a bug bounty programme pays rewards for valid reports. VDPs are the safer, lower-pressure place to file your first reports.