I almost didn't check it. I'd been reporting bugs for three months at that point and had gotten nothing but duplicates and N/A's. I was tired. I figured it was another polite rejection dressed up in template language.

But I opened it anyway.

"Bounty awarded: $1,250."

I sat there and re-read that three times. I remember literally getting up and walking to the kitchen to get water because I didn't know what to do with the feeling. It wasn't just the money — though $1,250 felt enormous to me at the time. It was the proof. Proof that someone who'd taught themselves everything from YouTube videos, free labs, and late nights had found a real vulnerability in a real company's infrastructure. A company that paid me to tell them about it.

That was about fourteen months ago. Since then, I've made $47,000 on HackerOne. No degree. No bootcamp. No mentor handing me a roadmap.

This article is that roadmap — the one I wish existed when I started.

TL;DR for the impatient:

• The first 3 months will probably feel like nothing is working. That's normal, and it's temporary.
• Specialization beats broad knowledge every single time in bug bounty.
• Report writing is where most hunters leave real money on the table — it's fixable, and I'll show you how.

Where It Actually Started

I didn't study computer science. I studied something completely unrelated, dropped out after a year because I couldn't afford to continue, and spent the next eighteen months in a low-paying job that bored me into obsession. Obsession with how things break. With why systems fail. With the gap between how software is supposed to work and how it actually works under pressure.

I started with the basics — reading about how HTTP works, what a request looks like, what a response carries back. I broke my own janky test environments constantly. I failed a lot in private, where it didn't cost me anything except time.

Nobody handed me a credential. So I had to become genuinely good instead.

That's not a flex. It's actually the point. The bug bounty ecosystem rewards skill and persistence over paperwork. HackerOne's own data shows that their top earners span dozens of countries, many without formal CS education. The barrier isn't a degree — it's discipline.

The Mistake Everyone Makes at the Start

I made it too. For the first three months, I found absolutely nothing. Not because I wasn't working hard — I was grinding every night. I was making the mistake almost every beginner makes: going too broad.

I was jumping between XSS and SQL injection and business logic flaws and CSRF and API misconfigurations and authentication bypasses. I had seventeen browser tabs open. I was watching YouTube tutorials on four different vulnerability classes simultaneously. I thought breadth was the path to finding something.

It's not. Breadth is the path to finding nothing, faster.

The hunters who make real money — and I've talked to enough of them through the Bugitrix community to say this with confidence — they know one or two vulnerability classes deeply. Not casually. Deeply. They know the edge cases. They know how different frameworks handle the same input differently. They know what a good target looks like before they ever open Burp Suite.

I wasted two months chasing breadth. I'm telling you this so you don't.

The Actual Playbook

Phase 1: Choose Your Starting Ground Deliberately

Your first decision isn't what vulnerability to learn. It's where to hunt.

There are two main program types: Vulnerability Disclosure Programs (VDPs) that don't pay money, and paid bug bounty programs that do. Almost every beginner skips VDPs because "why would I work for free?"

Here's what nobody tells you: VDPs are where you build the pattern recognition that makes you money later.

I spent my first eight weeks exclusively on VDPs. Large tech companies run them — Google, Meta, GitHub all have disclosure programs. The scope is often wide, the expectation of polish is lower, and you can practice submitting real reports without the psychological pressure of chasing a payout. You start understanding triage. You start understanding why some reports get closed immediately and others get escalated.

When I moved to paid programs, I wasn't starting from zero. I was starting with a mental library of what companies actually care about and what their engineers respond to.

Start on VDPs. Stay there long enough to submit at least five real reports. Then move.

Phase 2: Go Uncomfortably Deep on One Vulnerability Class

I chose IDOR — Insecure Direct Object Reference. Not because it's the most glamorous bug class. Because it's everywhere, it's consistent, and once you truly understand it, you start seeing it in places other hunters scroll past.

An IDOR, at its core, is when an application exposes a reference to an internal implementation object — a user ID, a file ID, an order number — and doesn't properly verify that the person making the request should have access to it. Simple concept. Enormous real-world surface area.

I spent six weeks doing nothing but IDORs. I went through every PortSwigger Web Academy lab on access control. I read every public IDOR writeup I could find on HackerOne's disclosed reports. I built test environments and broke them myself. I stopped being someone who "knew what an IDOR was" and started being someone who could find them reliably.

The payout pattern followed the knowledge curve almost exactly. My first IDOR paid $400. The next one paid $900. The one after that was $2,500 because I'd found a horizontal privilege escalation affecting user financial data — the kind of bug that companies take seriously because it affects their customers directly.

Pick one class. Go uncomfortably deep. XSS, SSRF, and IDOR are all strong starting choices — but pick one and stay there until you stop having to think consciously about the fundamentals.

"The hunters who earn consistently aren't the ones who know a little about everything. They're the ones who know something deeply enough that they see what everyone else walked past."

If you're learning this and want a community to ask questions in, join us on Telegram: t.me/bugitrix

Phase 3: Recon Is Not Optional — It's Your Actual Edge

Here's the honest truth about recon: most beginners skip it or do it badly, which means the hunters who do it well have a structural advantage. That's you, if you pay attention here.

Good recon isn't about running every tool you've heard of. It's about building a more complete picture of an attack surface than the company's own security team has bothered to map recently.

My core recon stack is small and consistent. Subfinder and Amass for subdomain enumeration — together, they find more than either does alone, and subdomains are where forgotten, under-maintained infrastructure lives. Forgotten infrastructure is where bugs live. I pipe their output through httpx to figure out what's actually alive, and then I load what's interesting into Burp Suite for manual investigation.

Burp Suite is the one tool you genuinely cannot skip. Learn it properly. The free Community Edition is enough to start — Burp's proxy, the Repeater, the Intruder. Understand what it's showing you at the HTTP level. The hunters who use Burp as a passive traffic viewer and nothing else are leaving discovery on the table.

The mindset shift that actually changed my recon was this: I stopped asking "what can I find on this target" and started asking "what has this company probably forgotten about?" Staging environments accidentally left public. Old mobile API endpoints that never got deprecated. Subdomains pointing to third-party services that were cancelled but never cleaned up — ripe for subdomain takeover.

Recon isn't a checklist. It's a question: where is this company not paying attention?

Phase 4: Your Report Is Half the Battle — Most Hunters Get This Wrong

I've seen hunters lose $500 to $2,000 in payouts not because their bug wasn't real or wasn't impactful, but because their report didn't communicate the impact clearly enough.

Triage teams process dozens of reports. If your report makes them work to understand the severity, they'll resolve it at a lower impact rating. That lower rating means a lower payout — or sometimes a close without one.

Here's a real example from my own reports. The same IDOR vulnerability, two ways to write it up:

Bad report:

"I found an IDOR vulnerability in the /api/orders endpoint. By changing the order ID in the request, I can access other users' orders. This is a security issue."

What I actually submitted:

"Unauthenticated IDOR in /api/orders/{id} allows horizontal privilege escalation across all user accounts.

Steps to reproduce: [numbered, exact steps with request/response included as Burp captures]

Impact: An attacker with any valid authenticated session can enumerate all order IDs and retrieve the full order history, delivery addresses, and partial payment information of any other user. At current user scale (~2M accounts per public disclosure), this represents a systemic data exposure affecting the platform's entire user base.

Suggested remediation: Validate that the authenticated user's ID matches the user_id field on the retrieved order object server-side before returning the response."

The difference isn't length. It's specificity, reproducibility, and impact framing. The second report tells the triage engineer exactly what is broken, exactly how to verify it, and exactly why their business should care.

Write reports for tired people who need to justify escalating your finding to their manager. Make their job easy. They'll reward you for it.

The $47,000 Breakdown

I want to be specific here because vague numbers help nobody.

The $47,000 over fourteen months broke down roughly like this: about $21,000 came from IDOR and access control vulnerabilities — my strongest area and where I focused most of my time. Around $12,000 came from SSRF findings, which I moved into seriously around month eight once I had a deep enough understanding of how server-side requests behave in cloud infrastructure. The remaining $14,000 is scattered across XSS, a handful of business logic flaws, and one particularly impactful authentication bypass that paid $4,800 alone on a well-funded fintech program.

On HackerOne specifically, roughly 70% of my total earnings came from about eight programs I kept returning to. I'm not in a different program every week. I understand specific targets. I know their stack, their deployment patterns, their scope edges. Familiarity compounds.

The first three months: $0. Months four through six: about $4,200 total, mostly smaller payouts as I found my footing on paid programs. From month seven onward, the monthly floor never dropped below $2,800.

The growth isn't magic. It's what happens when you invest the first several months in building real skill rather than chasing payouts before you're ready.

I share more breakdowns like this at bugitrix.com — free resources, writeups, and tools.

What Separates $500/Month Hunters from $5,000/Month Hunters

The honest answer isn't talent. It's three specific differences that I've noticed consistently.

First: hunters at the higher end treat recon as a continuous process, not a one-time step. They're not doing recon before a session. They're running lightweight monitoring on their target programs so they notice when new subdomains appear, when scope expands, when new features go live. New features are where bugs live. The window after a feature launches — before it's been hardened — is where you want to be.

Second: they write reports like professionals. We covered this above but it really is that significant a separator.

Third — and this is the one people don't talk about enough — they have opinions about their targets. They've spent enough time in specific programs that they understand the architecture, the tech stack, the team's apparent security posture. They're not generically hunting. They're hunting a specific place they understand well.

The $500/month hunters are still searching for the approach. The $5,000/month hunters have one and they're executing it consistently.

Resources That Actually Helped

I'm only listing free resources here, because there's genuinely no reason to pay for introductory content.

PortSwigger Web Academy is the single best free resource in this field. Full stop. Their labs cover every major web vulnerability class with hands-on exercises. I've done most of them twice. If you haven't started here, start here.

HackTheBox for building general enumeration and exploitation skills. The free tier is enough to get started. The Retired Machines section, once you're a member, comes with community writeups that teach you how experienced people think through problems.

HackerOne's own disclosed reports are criminally underused as a learning resource. Real bugs, real impact descriptions, real bounty amounts. Read ten disclosed reports in your chosen vulnerability class and you'll understand the standard faster than any tutorial.

Subfinder and Amass are both free and open source. Learn to use them together. Their GitHub repositories have solid documentation.

That's genuinely what I used. Nothing behind a paywall, nothing that required a course fee.

If you want me to personally guide your bug bounty journey, I do 1:1 mentorship — limited spots: Apply here

This Is Actually Possible for You

I want to be careful here not to make this sound easy. It isn't easy. The first three months of finding nothing is genuinely discouraging, and I won't tell you otherwise. There are weeks where everything feels like a dead end. There are good reports that still come back as duplicates. There's frustration built into the process.

But the path is real. The skills are learnable. The earning potential is not hype — HackerOne has paid out over $300 million to researchers since the platform launched, and the demand for people who can find real vulnerabilities is only growing.

You don't need a degree. You need obsession, patience, and a willingness to spend months getting genuinely good at one specific thing before you expect the results to follow.

The money followed the skill. In that order, not the reverse.

Start Here Today

Step 1: Create a free account on PortSwigger Web Academy and complete the Access Control labs. All of them. This week.

Step 2: Create a HackerOne account and read ten recently disclosed IDOR or XSS reports on programs you find interesting. Pay attention to how the impact is described — not just what the bug is.

Step 3: Pick one VDP from a company you use or respect. Run Subfinder on their scope. Find one interesting subdomain. Load it in Burp. Spend two hours understanding how it behaves before you look for anything to break.

That's it. That's the start.

The rest is just doing it again, getting better each time.

Bugitrix is where I share ongoing research, tools, and writeups from the field. If you're building a career in security or just trying to understand how this world actually works — come find us.

And if you want your resume or LinkedIn optimized for security roles or bug bounty credibility, I help with that too: Apply here