Someone messages me every week with some version of the same question: "I have zero knowledge about hacking. I want to do bug bounty. Where do I start?" Most answers online are either vague ("learn networking!") or dishonest ("I made $5k in my first month!"). This post is neither
I'm going to give you a week-by-week plan, the exact free resources to use, the realistic timeline to your first $1,000, and the honest reasons most beginners never get there. Read it all before you start — especially the uncomfortable parts.
The honest answer to "how long?"
If you study 2 hours per day consistently: your first payout — even a small one — will likely arrive between month 4 and month 7. Your first $1,000 total earned will likely happen between month 6 and month 10. Not month one. Not week three. Six to ten months of consistent work from absolute zero.
Reality check — absolute beginner, 2hrs/day
First accepted report (any amount) -Month 3–5
First actual payout received -Month 4–7
$1,000 total earned -Month 6–10
$1,000 in a single month -Month 10–18
Consistent $3k+/month -Month 18–30
Why it takes this long: Bug bounty is not a skill you can cram. It's pattern recognition built from hours of hands-on practice. There's no shortcut. Anyone telling you otherwise wants to sell you something.
Those timelines assume you follow a structured path, not random YouTube videos. Here is that path.
Week 1–2
Learn Understand how the web works — really.
Complete the "Web Fundamentals" path on PortSwigger Web Academy (free). Learn what HTTP requests and responses are. Understand cookies, sessions, and how a browser talks to a server. Do not skip this. Every bug you ever find lives in this layer.
Week 3–4
Learn Install and learn Burp Suite Community.
This is your main tool for the rest of your career. Set it up as a proxy between your browser and the internet. Learn to intercept requests, modify them, and resend them. PortSwigger has free Burp tutorials built into the Academy. Use them.
Week 5–7
Learn Study your first three vulnerability classes — deeply.
Do NOT try to learn everything at once. Learn only these three: IDOR (broken access control), reflected XSS, and information disclosure. Read the PortSwigger Academy pages. Complete every lab for each topic. Understand why each one happens, not just how to trigger it.
Week 8–9
Practice Practice on legal hacking labs — not real targets yet.
Sign up for HackTheBox (free tier) or TryHackMe (free tier). Complete 5–10 beginner web challenges. This builds the reflex of looking for vulns without the pressure of real programs. You will feel slow and lost — that is normal.
Week 10
Practice Create accounts on HackerOne and Bugcrowd.
Do not start hunting yet. Just read 20–30 disclosed (public) bug reports on HackerOne. Filter for IDOR and access control. Read how real hunters wrote their reports. Notice the structure: summary, steps to reproduce, impact, suggested fix. Copy that structure into a blank template you keep.
Week 11–12
Hunt Pick your first program — carefully.
Go to HackerOne. Filter by: accepts all researchers, has a bounty table, response time under 5 days. Pick a small SaaS product — not Google, not Facebook, not Meta. Something with 10,000–500,000 users. A small fintech, a project management tool, a niche e-commerce API. Sign up as two users: your attacker and your victim account.
Week 13–16
Hunt Test access control on every feature you can find.
Log in as User A. Do everything the app lets you do — create orders, upload files, send messages, change settings. Capture every request in Burp. Note every ID number you see. Then log into User B and try to access User A's objects using those IDs. Write down everything you try. Report anything that works — even small things.
Month 4–5
Hunt First report submitted. Expect rejections — learn from them.
Your first several reports will likely be rejected: not a bug, duplicate, out of scope, or informational. This is not failure — it is paid education. Read every triage response carefully. Ask yourself: what did I misunderstand? Adjust your next report. One accepted report, even for $100, changes everything psychologically
Month 5–7
Earn First payout. Now systematize what worked.
When you get your first payout, stop and ask: what program type was this? What feature had the bug? What did I do differently? Write it down. Then repeat that exact approach on three more programs in the same category. One payout is luck. Three payouts from the same approach is a method.
Month 7–10
Earn Stack reports. Hit $1,000 total earned.
By now you have a repeatable process for one vulnerability class on one type of target. You are faster. You waste less time on dead ends. You know how to write a report that gets paid. Keep going — $1,000 total is not a salary yet but it proves the model works for you specifically.
The free resources — in order of use
PortSwigger Web Academy
HackerOne disclosed reports
Burp Suite Community
OWASP cheatsheet (for deep knowledge)
The five mistakes that kill beginners
01 .Targeting Google, Apple, or Meta first
These programs have thousands of full-time hunters. Every obvious bug was found years ago. You will get 100% duplicates, zero payouts, and quit in frustration. Target small SaaS companies with 10k–200k users. Less competition, less scrutiny, more beginner-accessible bugs.
02 .Learning too wide instead of too deep
Watching 40 YouTube videos about SQLi, XSS, SSRF, XXE, RCE, and IDOR gives you awareness of everything and mastery of nothing. Pick IDOR. Only IDOR. Spend two months becoming genuinely good at one thing before expanding. Depth pays. Breadth impresses no one.
03 .Skipping the lab phase and hunting immediately
Going straight to real programs before you understand basic vuln classes is like doing surgery after watching a YouTube video. You'll waste time, get demoralized by rejections, and learn nothing from them because you don't have enough foundation to understand the feedback.
04 .Writing lazy reports
A real bug with a bad report gets marked Informational or closed. "Found IDOR at /api/user" is not a report. Show the exact request, the exact response, the exact impact. If you can't articulate what an attacker can do with your finding, the triage team won't care about it.
05 .Quitting after the first duplicate
Your first duplicate feels like failure. It isn't — it means you found a real vulnerability. The only problem is timing. Duplicates are proof of concept that your skills are developing. Log what you found, note the program, and move to a less-tested target. Never report the same bug class twice on the same program without checking first.
The one thing that separates earners from quitters
It's not intelligence. It's not having the best tools. It's documentation. Every session you hunt, write down what you tested, what you tried, what came back, and what you'll try differently next time. Hunters who document compound their knowledge. Hunters who don't repeat the same mistakes for months and burn out.
Keep a simple text file or Notion page. Date, target, what you tested, results. That's it. Do it every single session. When you go back to a program after two weeks away, you'll know exactly where to pick up instead of starting over.
Your week-one action list: Create a free PortSwigger account today. Complete the "What is HTTP?" module tonight. Do not install Kali Linux. Do not buy a course. Do not set up a "hacking lab VM." Learn what HTTP is first. Everything else comes after that foundation exists.
Six to ten months from zero to $1,000. That's the real number. It's longer than the hype says and shorter than most people assume when they actually sit down and do the math on their learning time. The path is real. The resources are free. The only question is whether you'll still be doing it in month five when it feels like nothing is working.
Most people quit in month two. The ones who don't are the ones who get paid.
Always read a program's policy before testing. Never test outside defined scope. Keep notes on everything.