It is late, the house is quiet, and you are poking at a password reset flow on a site that has invited people like you to test it. You change one field, resend the request, and the server hands you back a token belonging to someone else's account. Your heart jumps. You just found something real.
Compare that feeling with your day job. Tickets, meetings, a manager who takes credit, and a salary that barely moved while your rent climbed. Maybe you are already technical and bored. Maybe you are learning and every job post asks for experience you cannot get.
Bug bounties reward people who get good before everyone else catches up. The newest programmes and the freshest features are where unfound bugs gather, and every month more hunters arrive with better tools and AI helpers. Your best years for low-hanging findings are the early ones, before you are competing with an army that started when you were still thinking about it.
Know the numbers going in. The average submission payout was $783, and the top 50 researchers averaged $145,000 in total payouts. Plenty of your evenings will end with nothing found, which is why monthly income here swings between $0 and about $3,000 and why it takes 3 to 12 months before it steadies into anything. Your tools and setup cost between $0 and $300.
Tonight, do the cheapest part of the whole thing. Pick one public programme and read its scope and policy page to the very end, so you know which domains you are allowed near and which are off limits.
Look closely at the word "total" in that second figure. It means cumulative career earnings for the very best hunters on the platform. Nobody is drawing that as a yearly salary. The first figure, what an accepted submission is worth on average, is the one that actually applies to you.
Bugcrowd surveyed more than 750 of its researchers, and their answers fill in the rest of the picture. Half were bug hunting on top of a regular nine-to-five job. Sixty-six percent spent up to ten hours a week on it. Only 22% considered it their full-time profession, while 32% hoped to get there. Those figures come from its Inside the Mind of a Hacker reporting. The detailed breakdowns date from the platform's 2018 and 2019 editions, and the shape has stayed the same since: most people do this part time, alongside a job.
So here is the honest picture for you. A skill with a genuine ceiling, an extreme spread of results, and a typical experience of a few hours a week for a few hundred dollars a submission, on the weeks a submission lands.
Why give it a whole chapter, then? Because when you lose here, you still walk away with something, which is rare for anything with a lottery-shaped payout. Say you hunt for a year and earn almost nothing. You have still learned how real systems fail, how access control breaks in production, and how to write a technical finding a stranger can act on. All of that carries straight into engineering and security work that pays reliably. I would read the rest of this guide that way: treat the bounty income as the uncertain part and the skill as the part that compounds, and your risk drops a great deal.
If you have read the smart contract auditing guide on this site, you should know the money works quite differently here, and the difference helps you decide which one suits you. Which do you already know better: how websites break, or how Solidity breaks? Your answer is a good first filter.
So you know what kind of work this is and how it differs from the audit side. Next, let's settle what a single accepted finding is worth to you.
Each programme sets its own payouts and publishes them in the programme brief. That means you can read the terms before you spend a single evening.
Across HackerOne's public listings you will see a stated minimum bounty per programme, commonly in the $50 to $500 range, rising with severity to four and five figures for critical findings on well-funded targets. Some set their minimums far higher: Matomo lists a $10,000 minimum.
Programme totals give you a feel for how much money is moving around. Slack has awarded over $12 million across its HackerOne programmes since 2015. Zoom's private programme has awarded over $15 million since 2019.
For averages by severity, HackerOne reported that the average bounty for critical vulnerabilities across all industries reached $3,384, up 48% from $2,281 the year before. That figure comes from its 2019 reporting and rates have generally risen since. What matters for you is the order of magnitude: a critical finding on an average programme is worth low thousands. The six-figure sums you see in headlines are rare exceptions.
Put those numbers side by side and the sum is sobering. An average submission at $783, on a platform where two-thirds of researchers work under ten hours a week, will not pay your salary. It turns into a salary only for the small group who find severe issues again and again on high-paying programmes.
Still, one accepted report at the $783 average is real money for a single finding. Think new tyres for your car, or a dentist bill for the kids handled in one go, earned in the evenings after they are asleep. Enjoy it as a bonus, and keep your salary for the rent. What would one $783 report go to first in your house? Name it now, because a concrete goal helps on the evenings that find nothing.
Picture the email that says your report was accepted and paid. A bill you were dreading just became a bill you can pay, and you did it with skill nobody at work ever noticed. That moment changes how you see yourself, and it often matters more than the money.
Every published figure in this field points the same way. The community's own rule of thumb is that the top 5% of hunters earn roughly half of all bounties paid. That is an estimate rather than a platform statistic, and it fits everything the platforms do publish.
The headline stories say the same thing if you read them slowly. When HackerOne announced that six hackers had each earned over one million dollars, those were career cumulative totals, and the first person to reach that mark did so after years of work. In the same announcement, total hacker earnings across the whole platform for the year were $21 million. Six people had, over their careers, earned a real fraction of what the entire platform paid out in one year at that point.
This is a power law, and power laws are honest about who they reward. A few people who are very good, very fast and very persistent earn well. Most people find few valid bugs, and many find none at all in their first months.
The bugs that pay are the ones automated scanners miss. Scanners are cheap, and every programme already runs them against itself.
The thread running through all of it: you get paid for demonstrated impact. A theoretical issue with no shown consequence gets triaged low. Take the same underlying flaw, chain it into an account takeover with a working proof of concept, and you have a different report entirely.
That is the money side settled. Now for the boundary around all of it: whose permission you hold, and exactly how far it reaches.
Please read this section carefully. It is what separates bug bounty hunting from unauthorised access, and it is genuinely serious.
Never access more data than you need to demonstrate the issue. If you can read another user's record, prove it with one record and stop. Download a database to show the flaw is real and you turn a valid report into a serious incident that you caused.
Report, then wait. The programme sets the disclosure timeline. Publish before the agreed window, or before a fix, and you breach the terms and lose the payment.
Here is the way of thinking that keeps you safe: you have permission to do specific things to specific systems, granted in writing, and that permission is the only thing separating your work from an offence. Read it every single time.
How This Became a Legitimate Activity
The legal caution above comes from real history, and that history explains why programme terms read the way they do.
For most of the internet's commercial life, telling a company about a flaw in its product was risky. Researchers who reported vulnerabilities were sometimes thanked and sometimes threatened, and the company alone decided which. Computer misuse laws in most countries were drafted broadly, criminalising unauthorised access without separating someone stealing data from someone showing that data could be stolen. A researcher acting in good faith had no reliable protection, and several were prosecuted or sued.
That led to a long, bitter standoff. Some researchers published findings openly, arguing that public pressure was the only thing that got bugs fixed. Companies felt that as extortion. Neither side trusted the other, and ordinary users like you were less safe for it.
Bug bounty programmes ended the standoff by making the permission explicit. A published programme is a company saying, in writing and in advance, which systems you may test, which techniques are fine, what it will pay, and that it will not come after researchers who stay inside those lines. The safe harbour statement is the whole innovation. Everything else, the payouts and the leaderboards, sits on top of it.
Two things follow from this that matter to you directly.
The scope document is a legal instrument. It marks the edge of your permission, which is why "it was only slightly out of scope" will never work as a defence.
And a missing safe harbour statement tells you something. Some programmes accept reports without any commitment about legal action, and researchers have been threatened after reporting to them. If you see no safe harbour, take it as a reason to leave that programme alone.
Things have moved toward more protection. Coordinated vulnerability disclosure is now standard practice at large organisations, many governments run their own disclosure programmes, and prosecutors in several jurisdictions now try to separate good-faith research from criminal access. That trend is real. You still need to read the terms in front of you. When did you last read a legal page all the way to the bottom? Start with the scope page of the programme you picked tonight.
The Anatomy of a Report That Gets Paid
Write the same finding two ways and you get different severities and different money. This is the part of the work you can improve most, and the part most people neglect.
A title that states the impact. Skip "IDOR in /api/orders" and write "Any authenticated user can read arbitrary customers' order details, including addresses, via order ID". A triager reads dozens of reports a day; yours should make sense in one line.
Reproduction steps precise enough to follow blind. Exact requests, exact accounts, exact values. If the triager cannot reproduce it on the first try, your report is fighting their scepticism as well as their queue.
Show the impact, don't just claim it. "This could allow account takeover" is a claim. A sequence showing you taking over a test account you control is a demonstration. The gap between those two often decides whether you get a medium or a critical.
Evidence collected in proportion. Enough to prove the issue and no more. One record, and leave the rest of the table alone. This protects you and shows you are a professional at the same time.
A line on scope compliance. Name the in-scope asset you tested and the test accounts you used. It takes one line and removes a whole category of doubt.
A suggested fix. You don't have to include one, and it changes how people see you. It marks you as someone helping fix a product as well as someone reporting a bug.
No drama. Inflated severity, urgent language and threats of disclosure damage your credibility and your signal score. If the finding is real, it speaks for itself.
The fastest way to absorb all this is to read published resolved reports on the platforms, because you see the report, the triager's replies and the final payout together. That feedback is free, and most beginners never look at it. How many paid reports have you actually read? Aim for twenty in one bug class before you write your own.
Where to Start
That covers what the work is, what it pays and where the limits sit. From here it is about your first weeks and what you actually sit down and do.
You are lucky here: the learning path is unusually well stocked and mostly free.
Deliberately vulnerable practice applications exist for every major bug class. They are built to be broken, so you can watch each pattern work before you hunt for it in the wild. Working through a structured set of these is your fastest route from theory to recognising bugs on sight.
Public disclosure archives are the best study material you will find. Many programmes publish resolved reports after a fix, which gives you thousands of real vulnerabilities with the researcher's reasoning, the proof of concept and the payout attached. Read lots of them in one category and you will learn what a valid finding looks like far faster than any course could teach you.
Vulnerability disclosure programmes without bounties are your sensible first target. They accept reports and pay nothing, so far fewer people compete, and your chance of a first valid finding is much higher. What you gain is reputation on the platform and the experience of writing a report that survives triage, which is the thing that really holds people back.
Pick a narrow specialism. Compete across all of bug bounty and you compete with everyone. Which part of web apps do you already understand from your day job: logins, payments, file uploads? Start there. Choose one bug class or one technology stack and go deep. That is how people with day jobs find things others miss.
Newly launched programmes and newly added scope are where undiscovered bugs gather. Established programmes have been picked over for years by people with more time than you.
Your first valid report with your handle on it is a small turning point. You become someone who found a real flaw in software thousands of people use, and the company thanked you for it. Imagine telling your partner that over dinner. Pick one bug class and work through its practice labs this week so that report arrives sooner.
Thinking about it for another month buys you nothing but more scrolling after a job that drains you. The hunters who get paid next year are the ones opening a practice lab tonight. Pick one bug class, finish one lab before bed, and let tomorrow's version of you be a little more dangerous to bad code.
Choosing a Programme to Work
Early on, the target you choose shapes your odds more than your skill does, and most beginners choose badly by going for the most famous name they recognise.
Freshness beats prestige. A programme launched last month has scope nobody has looked at. A programme running since 2015 has been examined nonstop by thousands of people, many of them full time. The obscure target is the far better use of your evening.
Watch for scope added to established programmes. When a mature programme adds a newly acquired subsidiary, a new product or a new domain, that scope is fresh even though the programme is old. Platforms announce these, and for you the announcement is a starting gun.
Prefer complex applications over simple ones. Business logic flaws need business logic. A marketing site has almost none. An application with roles, permissions, workflows, payments and integrations gives you a large surface of intended behaviour to subvert.
Check the response metrics. Platforms publish average time to triage, time to bounty and resolution rates. A programme that takes months to reply costs you cash flow and patience, and a low resolution rate suggests your reports would go nowhere.
Read what they exclude. The exclusions list tells you what they already know about and what they won't pay for, which saves you the evenings you would spend finding it.
Match the bounty table to what you will realistically find. A programme paying $50 minimums is not worth deep investment. One with meaningful rewards for medium-severity findings respects your effort, since mediums are what most hunters actually find.
Think about how mature the organisation is. A company running its first programme often has more unfound bugs than a tech firm with a decade of security spending behind it. The less recognisable name is often your better hunting ground. Who is the least famous company with a programme you could open tonight? That one is probably your best bet.
Setting Up Without Spending Much
You can start with very little, which matters because your income floor is zero.
An intercepting proxy is your central tool, and the free tiers of the standard options will carry you a long way. Everything you do runs through it: viewing, changing and replaying requests.
A separate browser just for testing, with its own profile, so your testing traffic and your everyday browsing never mix. That keeps noise out of your proxy and saves you from the genuinely bad moment of firing a test request while logged into something personal.
Notes that will last months. Which targets, which endpoints, what you already tried and what you set aside. You will hunt the same target over and over for months, and your memory will not hold it all.
Reconnaissance tooling, mostly free and open source, for listing subdomains, endpoints and technologies. Automation really helps you here, because enumeration is mechanical work and exploitation needs your judgment.
Several test accounts. Most access control testing needs two accounts so you can show that one can reach the other's data. Set them up before you need them. Do you have a spare email address or two ready for this? Create them before your first session so the testing never touches your personal accounts.
What you can skip: expensive scanners, a powerful machine, a paid course. The programmes have already run the commercial scanners against themselves, so buying one mostly buys you duplicates.
Rookie Mistakes
Submitting scanner output. Every programme runs its own scanners. A report any tool can produce is a duplicate at best and a hit to your reputation at worst, and platforms track signal quality.
Reporting theoretical issues with no shown impact. Missing security headers and version disclosure are informational. Programmes get hundreds of these, and they drag down your signal score, which affects your access to private programmes later.
Skipping the scope section. This is the most costly mistake you can make, both because out-of-scope findings pay nothing and because testing outside scope may leave you with no legal protection.
Chasing high-profile programmes first. The most famous targets draw the most hunters and have been examined continuously for years. A less glamorous programme with fresh scope is a far better use of your evening as a beginner.
Writing poor reports. A valid finding described badly gets triaged low or rejected. A clear title, exact reproduction steps, shown impact and a working proof of concept separate one severity from the next, and severity is money.
Giving up at your first duplicate. Being beaten to a bug means your process worked and your timing was off. That is genuinely encouraging news, even though it feels like the opposite at the time.
Neglecting your signal and reputation. Platforms weigh your history when they hand out invitations to private programmes, which are less crowded and pay better. Sloppy early submissions cost you access to the part of this world where your odds improve.
Measuring Yourself Honestly
Once you have submitted work, some of it will be closed with nothing paid. You then have to work out whether you are in a slow start or need to change your approach.
Because effort and reward come apart in the short run, the usual feedback is useless and you need something else. The hunters who last track their process rather than their income.
Hours logged against valid findings, over quarters rather than weeks. A month with nothing means nothing. Four months with nothing, against a few hundred hours, tells you to change your target selection or your technique. Grinding harder won't fix it.
Your duplicate rate, read as good news. Duplicates mean you are finding real bugs and arriving late. A rising duplicate rate means your technique works and your targets are too crowded, which is a specific problem you can fix.
Your signal score on each platform. This decides private invitations, which decide your realistic income. It tracks your eventual earnings more closely than anything else, and beginners mostly ignore it.
Time from submission to triage. If your reports keep taking longer than a programme's stated average, your report quality is probably the reason.
What you learned each session. Unglamorous, and the most useful thing to track over a year. A session that found nothing but taught you a new attack pattern against a technology you will meet again still produced something. Counting that as output is largely how people get through the unrewarded stretches.
Set your review point in advance, in months rather than weeks, and make the call then. Don't decide during a bad fortnight. What date will you write in your calendar for that review? Put it there before your first submission.
Gotchas Worth Knowing
Triage can be slow, and you will sometimes disagree. Reports can sit for weeks, and severity is a judgment call you will sometimes lose. Mediation exists, and it won't always go your way.
You may not get to see the duplicate. You can be told a finding is a duplicate without seeing the original report. It is unsatisfying, and it is standard.
Programmes change scope and pause without warning. The recon you spent a week on can become worthless after a scope cut announced the same week.
Payment comes with verification and tax duties. Platforms will verify your identity, sanctions screening applies, and whether you can be paid can depend on where you live. Bounty income is taxable and usually counts as self-employment income, with nothing withheld for you.
Your day job may have an opinion. Tech employment contracts often include clauses about outside work and, more importantly, about security research. Some employers forbid it, some want you to disclose it, and some claim rights over your findings. Have you read the outside-work clause in your own contract? Check yours before you start.
Burnout is common and very particular. Long unrewarded stretches broken up by duplicates wear you down, and the community talks about it openly. You will last longer if you treat this as a hobby with occasional income than if you treat it as a job with unreliable pay.
Your reputation travels with you and stays. That cuts both ways. A history of low-quality submissions follows you, and the platforms are small enough that people remember how you behaved.
Working with someone is allowed, and few people do it. Most programmes let researchers team up and split a bounty, and experienced hunters pair up regularly. Two of you thinking about the same application catch more than two people working apart, and splitting smooths out the swings that make this so hard to keep doing. Agree the split before you start, well before anything lands.
The Progression That Actually Pays
Public bounty income is the least reliable money in this field, and it leads you into several things that are far steadier. Seeing the ladder early changes what you aim for.
Public programmes are where everyone starts and where the crowd is thickest. Their job for you is to build a track record. The pay is a side effect.
Private, invitation-only programmes are your first real step up. Fewer researchers are invited, so duplicates are rarer and your odds per hour improve a lot. Invitations go out based on signal and reputation, which is why sloppy early submissions cost you in a way you cannot see at the time.
Time-boxed paid engagements. The platforms sell pentest-style engagements to customers and staff them with vetted researchers at agreed rates. That is paid work with a defined scope and pay you can predict, and you get access through your public record. For most people who stay with this field, this is where they end up, more than bounty income.
A job in security. A visible bug bounty record is a genuine credential for application security roles. It shows something a certificate cannot: that you found real vulnerabilities in real systems that other people had missed.
Independent consulting. With a track record and a specialism, selling security assessments directly is a business with normal economics, far from a lottery.
Here is the strategic takeaway, and it mirrors the smart contract auditing route: treat the public leaderboard as your marketing. Aim for reputation and signal quality and you reach the tiers where the money is predictable. Aim only for quick bounty income and you stay stuck in the most crowded tier.
An invitation to a private programme is quiet proof that you are good at this. When a cousin asks over family dinner how you got into security, you can show them the reports behind your profile and watch their face. And should private work ever get close to 3,000 a month, the ceiling for this kind of hunting, picking up the bill for the whole table stops feeling like a stretch.
Against the Alternatives
Let's place this honestly, because several options on this site want the same evenings of yours.
Against smart contract auditing. Crypto security has a higher ceiling, a steeper technical floor, and duplicates that dilute your payout instead of zeroing it. Web bounty hunting is easier to start and has more free learning material. If you already write Solidity, the crypto side pays better; if you come from web development, this is your natural door.
Against skilled freelancing. Freelance rates give you predictable money for predictable effort. Bug bounty has no floor and an uncapped upside that goes to a small minority. As a main income for a beginner, freelancing wins on every measure except how interesting it is.
Against a security job. For most people, the sensible money answer is to use bug bounty as the credential that gets you an application security role, then keep hunting on the side. You keep the fun part of the work and never depend on it for rent.
Against other technical side income. What sets this apart is that the skill lasts and travels with you. Whether or not you earn bounties, you are learning how systems fail, which helps you in any engineering role. Few side activities give you that, and it is the strongest reason to try this even if the income never shows up.
Who This Suits
I'll be direct, because many people drop out, and it is mostly a poor fit for them rather than a lack of ability.
Be honest with yourself here: would you still poke at that password reset flow if it paid nothing? It suits you if you find the puzzle interesting for its own sake. That is the single best predictor. The unrewarded stretches are long enough that anyone here only for money stops before their first finding.
It suits you if you already build web applications. Knowing how these systems are put together, and where developers cut corners under deadline, gives you a real head start on where to look.
It suits you if you have a stable income. No floor, effort and reward out of step in the short run, and weeks between submission and payment. It makes a poor main income and a good second one, which is exactly what the survey shows: half of researchers hunting alongside a nine-to-five.
It suits you if you write clearly. Report quality sets severity, severity sets payment, and a big share of the skill is written communication.
It does not suit you if you need income by a certain date. Your first valid finding may be months away.
It does not suit you if rejection hits you hard. Duplicates, downgrades and disputes are routine, and they often feel unfair.
It does not suit anyone tempted to treat scope as a suggestion. Your permission is the only thing separating this from an offence, and the people who get into serious trouble are almost always the ones who tested something they were not authorised to test.
Behind the Scenes: A Hunting Session
Most of your time goes on reading, and very little of it looks like the films.
You pick a target from a programme brief and start with scope, slowly, because everything after depends on getting it right. Which domains, which applications, which techniques you may use, and what is explicitly excluded.
Then reconnaissance, which means listing things before you touch anything. What subdomains exist, what technologies are running, where the application's edges are, which endpoints exist that nothing obvious links to. This phase is dull and it is where most findings start, because bugs gather in the parts of an application nobody shows off in a demo.
Then you use the application properly, the way a real user would. Sign up, go through the main flows, and pay attention to what it is trying to do. You cannot spot a business logic flaw until you understand the intended logic, which is why you can't skip this step, though many people do.
Then the actual testing, which is a long run of small experiments. Change an identifier and see whose data comes back. Remove a parameter. Replay a request as a different user. Interrupt a multi-step flow halfway. Most of these give you nothing, quickly.
Then, now and then, something behaves strangely. Now your real work starts: is it a genuine security issue, how far does it reach, and can you show the impact? Half of these fall apart once you look closely, which is exactly why you look.
Then the report, which deserves more care than people give it. Title, reproduction steps precise enough that a triager reproduces it first time, shown impact, and a suggested fix.
Then you wait. Then, sometimes, a duplicate notice arrives.
How do you usually feel after a long evening that produced nothing? Prepare yourself for the emotional shape of it. Long flat stretches, the occasional sharp disappointment, and rare, real satisfaction when a finding lands. If you enjoy the puzzle itself, you will last. People doing it only for money mostly stop within a few months.
Where This Goes Next
What follows is my reasoning about where this is heading, offered as argument rather than forecast. The tooling points are the ones that should shape what you practise now.
Automated discovery keeps raising the floor. Scanners and ever more capable models will keep taking over the bug classes a pattern can catch. That pushes even more of the value into business logic and access control flaws, where you have to understand intent, and makes the reports beginners usually submit worth even less.
Reputation gates more of the money. Private, invitation-only programmes pay better and have less competition, and you get in on your signal history. Expect the gap between researchers with a reputation and those without to widen, which makes your early submission quality matter more than it feels like it does.
Scope keeps spreading to new surfaces. APIs, mobile applications, cloud configuration, supply chain and, more and more, AI system behaviour are all showing up in programme scopes. Getting early to a surface others haven't learned yet is the most reliable way for you to compete as a part-time hunter.
Bug bounty and paid pentesting are merging. Platforms already sell time-boxed engagements with vetted researchers at agreed rates. That is a job with predictable pay, and a public bounty record is your qualification for it. For most people this is the realistic destination.
The part-time shape is here to stay. Half of researchers hunting alongside a job, and two-thirds under ten hours a week, is a settled pattern. It reflects work with no income floor, best done by people whose rent does not depend on it. Ideally, that includes you.
The private invitations and the paid testing contracts go to researchers with a record. A record takes time, and nobody can buy it on short notice. Every month you start later is a month of history someone else is building ahead of you, in the same programmes you will want to join.