Two numbers from Bugcrowd's own reporting describe this activity better than any guide's income claim.
Note the word "total" in the second figure. That is cumulative career earnings for the very best hunters on the platform, not an annual salary. And the first figure is what an accepted submission is worth on average, which is the number that applies to you.
Bugcrowd's survey of more than 750 of its researchers fills in the rest of the shape. 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 percent considered it their full-time profession, while 32 percent aspired to. Those figures come from its Inside the Mind of a Hacker reporting, and while the detailed breakdowns date from the platform's 2018 and 2019 editions, nothing about the structure has changed: this is predominantly a part-time activity done alongside employment.
That is the honest frame. A skill with a genuine ceiling, an extreme distribution, and a median experience of a few hours a week for a few hundred dollars a submission when a submission lands.
It is worth saying why the activity is still worth a chapter despite that. Unlike most things with a lottery-shaped payout, the losing outcome here leaves you with something. Someone who hunts for a year and earns almost nothing has still learned how real systems fail, how access control breaks in production, and how to write a technical finding that a stranger can act on. Those transfer directly into engineering and security work that pays reliably. The guide below is written on that basis: treat the bounty income as the uncertain part and the skill as the compounding part, and the risk of the whole exercise drops considerably.
If you have read the smart contract auditing guide on this site, the economics here are structurally different and the difference matters for which one suits you.
Payouts are set per programme and published in the programme brief, which means you can read the terms before spending any time.
The pattern across HackerOne's public listings is 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 programmes set minimums far higher: Matomo lists a $10,000 minimum.
Programme-level totals give a sense of the money in circulation. Slack has awarded over $12 million across its HackerOne programmes since 2015. Zoom's private programme has awarded over $15 million since 2019.
For severity-based averages, HackerOne reported that the average bounty for critical vulnerabilities across all industries reached $3,384, up 48 percent from $2,281 the year before. That figure is from its 2019 reporting and rates have generally risen since, but the order of magnitude is the useful part: a critical finding on an average programme is worth low thousands, not the six-figure sums that circulate in headlines.
Put the numbers together and the arithmetic is sobering. An average submission at $783, on a platform where two-thirds of researchers work under ten hours a week, is not a salary. It becomes one only for people who find severe issues consistently on high-paying programmes, which is a small group.
Every published figure in this field points the same way, and the community's own rule of thumb is that the top 5 percent of hunters earn roughly half of all bounties paid. That is an estimate rather than a platform statistic, and it is consistent with everything the platforms do publish.
The headline stories reinforce it if you read them carefully. 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 entire platform for the year were $21 million. Six individuals had, over their careers, earned a meaningful fraction of what the whole platform paid annually at that point.
This is a power law, and power laws are honest about who they reward. A small number of people who are very good, very fast and very persistent earn well. The large majority find few valid bugs, and many find none at all in their first months.
The vulnerability classes that pay are not the ones automated scanners find, for exactly the reason that scanners are cheap and every programme runs them already.
The unifying insight: pay tracks demonstrated impact, not cleverness. A theoretical issue with no demonstrated consequence is triaged low. The same underlying flaw, chained into an account takeover with a working proof of concept, is a different report entirely.
This is the section that separates bug bounty hunting from unauthorised access, and it is genuinely serious.
The framing that keeps people safe: you have permission to do specific things to specific systems, granted in writing, and the permission is the only thing separating this from an offence. Read it every time.
The legal caution above is not paranoia. It is the residue of how this field came to exist, and the history explains why programme terms are written the way they are.
For most of the internet's commercial history, telling a company about a flaw in its product was risky. Researchers who reported vulnerabilities were sometimes thanked and sometimes threatened, and the decision belonged entirely to the company. Computer misuse legislation in most countries was drafted broadly, criminalising unauthorised access without distinguishing between someone stealing data and someone demonstrating that stealing data was possible. A researcher acting in good faith had no reliable protection, and several were prosecuted or sued.
That produced a long, unproductive standoff. Some researchers published findings openly on the grounds that public pressure was the only mechanism that got things fixed. Companies experienced that as extortion. Neither side trusted the other and users were less safe for it.
Bug bounty programmes resolved 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 acceptable, what it will pay, and that it will not pursue researchers who stay inside those lines. The safe harbour statement is the entire innovation. Everything else, the payouts and the leaderboards, is built on top of it.
Two consequences follow that matter to you directly.
The scope document is a legal instrument rather than an administrative detail. It is the boundary of your permission, which is why "it was only slightly out of scope" is not a defence.
And the absence of a safe harbour statement is meaningful information. Programmes exist that accept reports without offering any commitment about legal action, and researchers have been threatened after reporting to them. Treat a missing safe harbour as a reason not to test, not as a gap to overlook.
The direction of travel has been toward more protection: coordinated vulnerability disclosure is now standard practice at large organisations, many governments run their own disclosure programmes, and prosecutorial policy in several jurisdictions has moved toward distinguishing good-faith research from criminal access. That trend is real and it is not a substitute for reading the terms in front of you.
The Anatomy of a Report That Gets Paid
The same finding, written two ways, produces different severities and different money. This is the most improvable part of the whole activity and the most neglected.
A title that states the impact. Not "IDOR in /api/orders" but "Any authenticated user can read arbitrary customers' order details, including addresses, via order ID". A triager reads dozens of reports; yours should be understood 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 attempt, your report is competing against their scepticism as well as their queue.
Demonstrated impact, not asserted impact. "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 phrasings is frequently the gap between a medium and a critical.
Evidence collected proportionately. Enough to prove the issue, and no more. One record, not the table. This protects you and signals professionalism at the same time.
A statement of scope compliance. Naming the in-scope asset you tested and the test accounts you used takes one line and removes an entire category of doubt.
A suggested remediation. Not required, and it materially changes how you are perceived. It marks the difference between someone reporting a bug and someone helping fix a product.
No dramatics. Inflated severity claims, urgency language and threats of disclosure damage your credibility and your signal score. The finding argues for itself if it is real.
Reading published resolved reports on the platforms is the fastest way to internalise this, because you see the report, the triager's responses and the final payout together. That feedback loop is available free and most beginners never use it.
Where to Start
The learning path here is unusually well-provisioned and mostly free.
Deliberately vulnerable practice applications exist for every major vulnerability class, designed to be exploited so you can see each pattern work before hunting for it in the wild. Working through a structured set of these is the fastest route from theory to recognition.
Public disclosure archives are the best study material in the field. Many programmes publish resolved reports after a fix, which means thousands of real vulnerabilities with the researcher's reasoning, the proof of concept and the payout attached. Reading these in volume, in one category, teaches you what a valid finding looks like far more efficiently than any course.
Vulnerability disclosure programmes without bounties are the sensible first target. They accept reports and pay nothing, which means far less competition, so your chance of a first valid finding is much higher. What you get is reputation on the platform and the experience of writing a report that survives triage, which is the thing that actually gates progress.
Pick a narrow specialism. Competing across all of bug bounty means competing with everyone. Choosing one vulnerability class or one technology stack and going deep is how people who are not full-time find things others miss.
Newly launched programmes and newly added scope are where undiscovered bugs concentrate. Established programmes have been picked over for years by people with more time than you.
Choosing a Programme to Work
Target selection determines your odds more than skill does, at least early on, and most beginners choose badly by picking the most famous name they recognise.
Freshness beats prestige. A programme launched last month has scope nobody has examined. A programme running since 2015 has been examined continuously by thousands of people, many of them full-time. The obscure target is the better use of an evening by a wide margin.
Watch for scope additions on 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 not. Platforms announce these, and the announcement is a starting gun.
Prefer complex applications over simple ones. Business logic flaws require business logic. A marketing site has almost none. An application with roles, permissions, workflows, payments and integrations has a large surface of intended behaviour that can be subverted.
Check the response metrics. Platforms publish average time to triage, time to bounty and resolution rates. A programme that takes months to respond costs you cash flow and patience, and a low resolution rate suggests reports go nowhere.
Read what they exclude. The exclusions list tells you what they already know about and what they will not pay for, which saves the time you would spend finding it.
Match the bounty table to your realistic findings. A programme paying $50 minimums is not worth deep investment. One with meaningful rewards for medium-severity findings respects the effort, since mediums are what most hunters actually find.
Consider the organisation's maturity. A company running its first programme frequently has more unfound bugs than a technology firm with a decade of security investment. Less recognisable is often better hunting.
Setting Up Without Spending Much
The tooling floor is low, which matters because the income floor is zero.
An intercepting proxy is the central tool, and the free tiers of the standard options are sufficient for a long time. Everything you do routes through it: viewing, modifying and replaying requests.
A browser kept separate for testing, with its own profile, so your testing traffic and your ordinary browsing never mix. This prevents both noise in your proxy and the genuinely bad outcome of firing a test request while logged into something personal.
Note-taking that survives months. Which targets, which endpoints, what you already tried and what you deferred. Hunting the same target repeatedly over months is normal, and memory is not sufficient.
Reconnaissance tooling, mostly free and open source, for enumerating subdomains, endpoints and technologies. This is where automation genuinely helps, because enumeration is mechanical and exploitation is not.
Test accounts, several of them. Most access control testing requires two accounts to demonstrate that one can reach the other's data. Set them up before you need them.
What is not required: expensive scanners, a powerful machine, or 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 that any tool produces is a duplicate at best and a reputation cost at worst, and platforms track signal quality.
Reporting theoretical issues with no demonstrated impact. Missing security headers and version disclosure are informational. Programmes receive hundreds of these and they damage your signal score, which affects your access to private programmes later.
Ignoring the scope section. The most consequential mistake available, both because out-of-scope findings pay nothing and because testing outside scope may have no legal protection.
Chasing high-profile programmes first. The most famous targets attract the most hunters and have been examined continuously for years. A less glamorous programme with fresh scope is a far better use of a beginner's evening.
Writing poor reports. A valid finding described badly gets triaged low or rejected. A clear title, exact reproduction steps, demonstrated impact, and a working proof of concept are the difference between severities, and severity is money.
Giving up at the first duplicate. Being beaten to a bug means your process worked and your timing did not. That is genuinely encouraging information, and it feels like the opposite.
Neglecting signal and reputation. Platforms weight your history when granting access to private programmes, which are less competitive and pay better. Early sloppy submissions cost access to the part of the ecosystem where the odds improve.
Measuring Yourself Honestly
Because effort and reward decouple in the short run, the usual feedback signal is useless and something has to replace it. The hunters who last track process rather than 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, means your target selection or your technique needs changing rather than more persistence.
Duplicate rate as a positive signal. Duplicates mean you are finding real bugs and arriving late. A rising duplicate rate means your technique is working and your target selection is too crowded, which is a specific and fixable problem.
Signal score on each platform. This determines private invitations, which determine your realistic income. It is the metric most correlated with eventual earnings and the one beginners ignore.
Time from submission to triage. If your reports consistently take longer than a programme's stated average, your report quality is probably the reason.
What you learned per session. Unglamorous and the most useful over a year. A session that found nothing but taught you a new attack pattern against a technology you will meet again has produced something, and treating that as output is largely how people survive the unrewarded stretches.
Set a review point in advance, in months rather than weeks, and decide then rather than during a bad fortnight.
Gotchas Worth Knowing
Triage can be slow and disagreements happen. Reports can sit for weeks, and severity assessments are judgment calls you will sometimes lose. There are mediation processes and they do not always go your way.
Duplicate determinations are not always visible. You may be told a finding is a duplicate without seeing the original report, which is unsatisfying and standard.
Programmes change scope and pause without notice. Time invested in reconnaissance on a target can be made worthless by a scope reduction announced the same week.
Payment carries verification and tax obligations. Platforms require identity verification, sanctions screening applies, and eligibility can depend on your jurisdiction. Bounty income is taxable and usually self-employment income, with nothing withheld.
Your day job may have something to say. Employment contracts in technology frequently include clauses about outside work and, more importantly, about security research. Some employers prohibit it, some require disclosure, and some claim rights over findings. Check before starting.
Burnout is common and specific. Long unrewarded stretches punctuated by duplicates is a demotivating pattern, and the community discusses it openly. Treating it as a hobby with occasional income survives that better than treating it as a job with unreliable pay.
Reputation is portable and permanent. Both good and bad. A history of low-quality submissions follows you, and the platforms are small enough that behaviour is remembered.
Collaboration is allowed and underused. Most programmes permit researchers to work together and split a bounty, and experienced hunters pair regularly. Two people reasoning about the same application catch more than two people working separately, and splitting reduces the variance that makes this activity hard to sustain. Agree the split before you start rather than after something lands.
The Progression That Actually Pays
Public bounty income is the least reliable money in this field, and it is the entry point to several things that are not. Understanding the ladder early changes what you optimise for.
Public programmes are where everyone starts and where competition is heaviest. Their function is to build a track record rather than to pay you.
Private, invitation-only programmes are the first real improvement. Fewer researchers are invited, so duplicates are rarer and the odds per hour improve substantially. Invitations are granted on signal and reputation, which is why sloppy early submissions are expensive in a way that is invisible at the time.
Time-boxed paid engagements. The platforms sell pentest-style engagements to customers and staff them with vetted researchers at agreed rates. This is paid work with a defined scope and predictable compensation, and access is granted on your public record. For most people who stick with this field, it is the destination rather than bounty income.
Employment in security. A visible bug bounty record is a genuine credential for application security roles, and it demonstrates 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 rather than lottery economics.
The strategic reading, and it mirrors the smart contract auditing route: the public leaderboard is a marketing asset, not a salary. Optimising for reputation and signal quality gets you to the tiers where the money is predictable. Optimising for immediate bounty income keeps you in the most competitive tier indefinitely.
Against the Alternatives
Worth situating honestly, because several options on this site compete for the same evenings.
Against smart contract auditing. Higher ceiling in crypto security, steeper technical floor, and a duplicate structure that dilutes rather than zeroes. 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 are starting from web development, this is the natural door.
Against skilled freelancing. Freelance rates produce predictable money for predictable effort. Bug bounty has no floor and an uncapped upside that accrues to a small minority. As a primary income for a beginner, freelancing wins on every measure except interest.
Against a security job. The realistic financial answer for most people is to use bug bounty as the credential that gets an application security role, then keep hunting as a side activity. That captures the interesting part of the work without depending on it for rent.
Against other technical side income. The distinguishing feature here is that the skill is durable and transferable. Whether or not you earn bounties, you are learning how systems fail, which is valuable in any engineering role. Few side activities have that property, and it is the strongest argument for trying it even if the income never materialises.
Who This Suits
Direct, because the dropout rate is high and mostly reflects mismatch rather than ability.
It suits people who find the puzzle intrinsically interesting. This is the single best predictor. The unrewarded stretches are long enough that anyone motivated only by money stops before the first finding.
It suits people who already build web applications. Knowing how these systems are constructed, and where developers cut corners under deadline, is a genuine head start on knowing where to look.
It suits people with a stable income. No floor, uncorrelated effort and reward in the short run, and weeks between submission and payment. It is a poor primary income and a good secondary one, which is exactly what the survey data shows: half of researchers hunting alongside a nine-to-five.
It suits people who write clearly. Report quality determines severity and severity determines payment, and a substantial fraction of the skill is written communication rather than technical.
It does not suit people who need income on a timeline. Your first valid finding may be months away.
It does not suit people who take rejection badly. Duplicates, downgrades and disputes are routine and frequently feel unfair.
It does not suit anyone inclined to treat scope as a suggestion. The 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
The reality is mostly reading, and very little of what films depict.
You pick a target from a programme brief and start with scope, carefully, because everything after depends on getting that right. Which domains, which applications, which techniques are permitted, what is explicitly excluded.
Then reconnaissance, which is enumeration rather than exploitation. What subdomains exist, what technologies are running, where the application's boundaries are, which endpoints exist that are not linked from anywhere obvious. This phase is unglamorous and it is where most findings originate, because bugs concentrate in the parts of an application nobody demonstrates.
Then you use the application properly, as a real user would. Sign up, complete the main flows, and pay attention to what the application is trying to do. You cannot spot a business logic flaw without understanding the intended logic, which is why this step cannot be skipped and often is.
Then the actual testing, which is a long sequence 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 midway. Most of these produce nothing, quickly.
Then, occasionally, something behaves unexpectedly. Now the real work starts: establishing whether it is a genuine security issue, how far it reaches, and whether you can demonstrate impact. Half of these collapse on examination, which is the point of examining them.
Then the report, which deserves more care than people give it. Title, reproduction steps precise enough that a triager reproduces it first time, demonstrated impact, and a suggested fix.
Then waiting. Then, sometimes, a duplicate notice.
The emotional shape is the thing to prepare for. Long flat stretches, occasional sharp disappointment, and infrequent genuine satisfaction when a finding lands. People who enjoy the puzzle itself last. People doing it only for money mostly stop within a few months.
Where This Goes Next
Reasoning about where this goes, 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 increasingly capable models will keep absorbing the pattern-matchable vulnerability classes. That further concentrates value in business logic and access control flaws, where understanding intent is required, and further devalues the reports beginners tend to submit.
Reputation gates more of the money. Private, invitation-only programmes pay better and have less competition, and access is granted on signal history. Expect the gap between researchers with reputation and those without to widen, which makes early submission quality more consequential than it feels.
Scope keeps expanding into new surfaces. APIs, mobile applications, cloud configuration, supply chain and increasingly AI system behaviour are all appearing in programme scopes. Being early on a surface others have not learned yet is the most reliable way for a part-time hunter to compete.
Bug bounty converges with paid pentesting. Platforms already sell time-boxed engagements with vetted researchers at agreed rates. That is a job with predictable pay rather than a lottery, and a public bounty record is the qualification for it. For most people this is the realistic destination.
The part-time shape persists. Half of researchers hunting alongside a job, and two-thirds under ten hours a week, is not a transitional state. It reflects an activity with no income floor, which is best undertaken by people whose rent does not depend on it.