How to Start Bug Bounty Hunting: A Complete Beginner’s Roadmap
Every week I get messages that read some version of the same thing: “I want to get into bug bounty hunting, but I don’t know where to start. There’s too much to learn and everyone online is either flexing their payouts or drowning me in tool names.”
This guide is the answer I wish someone had handed me. It’s a roadmap, not a highlight reel: the actual sequence of skills, the tools that matter (and the ones you can ignore for now), how to choose a first target that isn’t already picked clean, and how to write a report that gets triaged and paid instead of closed as a duplicate.
No shortcuts are promised, because there aren’t any. But there is a path, and it’s walkable.
What bug bounty hunting actually is
A bug bounty program is a standing invitation from a company: find security vulnerabilities in our systems, report them responsibly, and we’ll pay you. Companies run these programs because a crowd of skilled testers, paid only for results, finds problems their internal teams and automated scanners miss.
You, the hunter, get three things: legal authorisation to test real production systems, money for valid findings, and a feedback loop that turns theory into instinct (the part beginners undervalue).
The critical word is authorisation. A bug bounty program’s policy page is a legal document. It lists the domains and assets that are in scope, the attack types that are allowed, and the things you must never do (usually: no denial-of-service, no social engineering, no testing other users’ accounts without permission, no automated scanning that degrades service). Staying inside that scope is what separates ethical hacking from a crime. We’ll come back to this because it matters more than any technique.
The mindset that separates hunters from quitters
Before any tool or technique, understand what you’re actually signing up for, because the wrong expectations are why most people quit in week three.
Bug bounty is not passive income. It is a skill you build slowly and then apply. The first weeks are unglamorous: reading documentation, breaking labs, studying other people’s reports, and staring at applications until you understand what they’re supposed to do.
You are competing with a global crowd. On popular programs, thousands of experienced hunters have already tested the obvious things. This is why beginners who go straight for a famous target’s login page find nothing and conclude they’re not good enough. They’re not bad. They’re late. The skill isn’t running a scanner; it’s noticing the thing everyone else scrolled past.
Depth beats breadth. The hunter who deeply understands one class of vulnerability and one target will out-earn the one who superficially scans a hundred. Pick a lane, go deep, expand later.
If you can accept a few months of learning before your first payout, you’re already ahead of most of the people who start.
Phase 1: build the foundations (weeks 1-6)
You cannot exploit what you don’t understand. Before hunting anything, you need a working mental model of how the web actually functions.
Understand how the web works
Everything you’ll do as a hunter is manipulating HTTP requests and reading the responses. Get genuinely comfortable with:
- The request/response cycle: methods (
GET,POST,PUT,DELETE), status codes, headers, and bodies. - Cookies and sessions: how a server remembers who you are between requests, and why that mechanism is a constant source of bugs.
- The same-origin policy and CORS: the browser rules that decide which sites can talk to which, and what happens when they’re misconfigured.
A single annotated request tells you most of the story:
POST /api/v1/account/update HTTP/1.1
Host: target.example
Cookie: session=eyJ1c2VyIjoxMDQyfQ...
Content-Type: application/json
{"user_id": 1042, "email": "attacker@evil.example"}Look at that user_id in the body. What happens if you change it to 1043? That single question is the seed of an entire vulnerability class, and you can’t ask it until you can read the request.
Learn the OWASP Top 10 until it’s instinct
The OWASP Top 10 is the industry’s consensus list of the most critical web application risks. Don’t just read it. Learn to recognise each category in a live application. Broken access control, injection, security misconfiguration, and authentication failures account for a large share of real bounty payouts. If you can explain each category to a friend and spot where it might hide in an app, you have the vocabulary of the field.
Get fluent with an intercepting proxy
Your browser hides the machinery. A proxy like Burp Suite (the Community edition is free and enough to start) sits between your browser and the target and lets you see and modify every single request. Learning to intercept a request, change a value, and forward it is the single most important practical skill in this phase. Everything else builds on it.
Practise on legal, deliberately vulnerable labs
Never learn a technique for the first time on a live target. Use environments built for exactly this:
- PortSwigger’s Web Security Academy: free, structured, and made by the team behind Burp Suite. Work through it category by category.
- OWASP Juice Shop: a deliberately broken web app you run yourself.
- PentesterLab and TryHackMe for guided paths.
Labs give you the one thing real targets don’t: a guarantee that the bug is there, so when you fail you know it’s your technique, not the target.
Phase 2: learn to do reconnaissance (weeks 6-10)
Most beginners skip straight to exploitation and wonder why they find nothing. Experienced hunters spend most of their time on reconnaissance, mapping everything a target exposes before attacking anything. You can’t find a vulnerability on an asset you never discovered.
Map the attack surface
A company is never just www.company.com. It’s a sprawl of subdomains, forgotten staging servers, old API versions, acquired products, and third-party integrations. Your job in recon is to find all of it and figure out which pieces are in scope.
Subdomain enumeration is where this starts. Staging and development subdomains are frequently less hardened than the flagship app: an old dev.company.com or api-v1.company.com that everyone forgot about is a classic source of findings. I’ve written a full walkthrough of the techniques in the subdomain enumeration recon guide, and you can get an instant first look at any domain’s subdomains using the free Subdomain Finder tool.
Fingerprint what you find
Once you have a list of live hosts, understand what each one is running. What web server? What framework? What security headers are present or missing? Misconfigured or absent security headers are both a finding in their own right and a signal that a host was set up carelessly, which often means other things were too. Run any target through the HTTP Header Analyzer to see its header posture in seconds, and check certificate hygiene with the SSL/TLS Checker.
Watch for the freshly exposed
Attack surface changes constantly: new subdomains appear, new features ship, old endpoints get deprecated. The best hunters stay current on new techniques and disclosed vulnerabilities so they can apply a fresh idea the day it drops. Keeping a daily pulse on offensive-security research (I built KeepLooped for exactly this) is a quiet edge most beginners ignore.
Phase 3: your first real hunt (weeks 10+)
Now you combine foundations and recon into actual hunting. Here’s how to give yourself the best possible odds.
Choose the right target
This is the decision that most determines whether a beginner succeeds. Avoid the famous flagship apps that every experienced hunter has already stripped bare. Instead look for:
- Programs with a wide scope:
*.company.comrather than a single hardened domain. Breadth means more forgotten corners. - Newer programs, or programs that recently expanded scope, before the crowd arrives.
- Vulnerability Disclosure Programs (VDPs) to practise on. They often don’t pay, but they’re lower competition and a great place to earn your first valid report and build confidence.
Before committing time, read a program’s past disclosed reports. They tell you what the triage team accepts, what they’ve already seen, and where this particular target tends to be weak.
Hunt where the money and the gaps are
For a beginner, the highest-value-per-effort bug classes are usually the logical ones, not the exotic ones:
- Broken access control / IDOR: the
user_id: 1042 → 1043question from earlier. Change an identifier, see someone else’s data. It’s the single most common serious finding in real testing and requires no special payload, just curiosity and careful observation. - Authentication and session flaws: password reset logic, weak session handling, missing rate limits on sensitive actions.
- Business-logic flaws: abusing the rules of the application: negative quantities, skipped steps in a checkout, coupon stacking. Scanners can’t find these; only someone who understands the app can.
The flashier injection bugs (SQL injection, cross-site scripting, server-side request forgery) are absolutely worth learning, and I have deep-dives on several. But as a beginner, the logical bugs give you the best return because they reward understanding over tooling, and understanding is the thing you’re building anyway. If you’re testing APIs specifically, my API security testing guide covers the methodology end to end.
Slow down and observe
The actual act of hunting is less dramatic than people imagine. You use the application the way a real user would, with Burp running in the background capturing everything. Then you go back through the requests and ask, at every single one:
- What does this parameter control?
- What happens if I change it to something I shouldn’t be allowed to send?
- Does the server check that I’m allowed to do this, or does it just trust me?
- What did the developer assume here that might not be true?
That’s it. That’s the job. The magic isn’t a tool. It’s the discipline of asking those questions on request after request until one of them returns something it shouldn’t.
The toolkit: what you actually need
Beginners drown in tool lists. Here’s the honest minimum, and the truth is that mastering a few beats collecting many.
| Purpose | Start with | Notes |
|---|---|---|
| Intercepting proxy | Burp Suite Community | The core of everything. Learn it deeply. |
| Browser | Firefox with a testing profile | Keep hunting separate from personal browsing. |
| Recon | Subdomain enumeration + a fingerprinting workflow | Use the free tools on this site to start without setup. |
| Note-taking | Anything you’ll actually use | Obsidian, a notebook, plain text. Document as you go. |
| Learning | PortSwigger Web Security Academy | Free, structured, authoritative. |
You do not need a paid Burp licence, a wall of automated scanners, or a Kali Linux install to find your first bug. You need the proxy, the browser, and the questions.
How to write a report that gets paid
Finding the bug is only half the work. A weak report on a real vulnerability gets closed; a clear report on a modest one gets rewarded and builds your reputation with the triage team. Every good report has the same bones:
- A clear, specific title. “IDOR in invoice endpoint exposes other users’ billing data,” not “found a bug.”
- Summary and impact. One paragraph: what the vulnerability is and, critically, what an attacker can actually do with it. Triagers prioritise by impact. Spell it out.
- Steps to reproduce. Numbered, exact, copy-pasteable. Assume the reader will follow them literally on the first try. Include the exact requests.
- Proof. A short screen recording or annotated screenshots showing the vulnerability working. Show, don’t just tell.
- Remediation suggestion. A brief, sensible fix. It shows you understand the root cause and makes the defender’s job easier.
Write for a tired engineer who has fifty reports to triage today. Clarity is a skill you’re paid for.
Stay in scope, always
One more time, because it’s the thing that ends careers before they start: only test what the program explicitly authorises. Do not test other users’ accounts without permission. Do not run aggressive automated scans that could take a service down. Do not touch assets that aren’t listed as in scope. When in doubt, ask the program or leave it alone. Your reputation and your legal safety both depend on this, and both are worth more than any single bounty.
Common beginner mistakes (and how to skip them)
- Quitting in month one. The learning curve is front-loaded. The people who “have a talent for this” are almost always just the ones who didn’t stop.
- Chasing the hardest bugs first. Exotic techniques are seductive. Logical bugs pay the rent while you learn the exotic ones.
- Picking picked-clean targets. Choose breadth and freshness over fame.
- Skipping recon. You can’t exploit what you never found. Time spent mapping the attack surface is never wasted.
- Ignoring disclosed reports. Every public report on HackerOne and Bugcrowd is a free lesson from someone who already succeeded. Read them constantly.
- Automating before understanding. A scanner in the hands of someone who doesn’t understand the output just produces noise and duplicate reports. Learn to hunt by hand first.
Your 90-day starting plan
If you want a concrete schedule, here’s one that works:
- Days 1-30: Web fundamentals + the OWASP Top 10 + Burp basics. Work through the PortSwigger Academy access-control and authentication labs. Goal: intercept and modify a request without thinking about it.
- Days 31-60: Learn reconnaissance. Practise subdomain enumeration and fingerprinting on your own domains and on lab targets. Read twenty disclosed reports and take notes on how the bug was found, not just what it was.
- Days 61-90: Choose one realistic program with a wide scope. Spend your sessions mapping it and hunting for access-control and logic bugs by hand. Submit your first report, even to a VDP, and refine it based on the response.
Ninety days of consistent, focused effort will not make you an expert. But it will take you from “I don’t know where to start” to “I’ve submitted a real report and I understand why it was valid.” That’s the hardest transition in the whole journey, and everything gets faster afterward.
Where to go from here
Bug bounty hunting rewards patience, curiosity, and a refusal to quit early. Build the foundations properly, respect the scope absolutely, and go deep before you go wide.
If you’d rather learn this with structure and direct feedback instead of piecing it together alone, that’s exactly what my hands-on training is built for: taking people from “I keep seeing terms I don’t understand” to confidently finding real bugs. And whenever you want to sharpen a specific skill, the free security tools and in-depth guides on this blog are here to help you practise.
Now close this tab, open a lab, and go break something you’re allowed to break.
