Bug Bounty Programs: A Complete Guide to Crowdsourced Security

An annual penetration test covers a codebase that changes forty times a day. The report describes an application that stopped existing somewhere around the second week of the engagement.

That mismatch is the entire commercial case for bug bounty programmes — Vulnerability Reward Programmes, if you prefer the formal name. Rather than buying a fixed window of two testers’ attention, you open a permanent intake channel and pay per validated finding, drawing on a pool of researchers who between them have looked at more authentication flows than any consultancy you could hire.

The economics are genuinely attractive and the model is genuinely limited, and most of the disappointment on both sides of it comes from confusing the two. This guide covers how the programmes run, what they are worth to an organisation, what researchers actually use, and — honestly — what the money looks like if you are thinking of hunting for a living.

What is a Bug Bounty Program?

A bug bounty programme is a standing, public invitation for external researchers to attack an organisation’s assets under published rules — defined scope, prohibited techniques, and a disclosure process — in exchange for payment on validated findings.

The word doing the heavy lifting is safe harbour. Without an explicit legal promise not to prosecute, everything described in this article is a criminal offence, and researchers know it. Programmes with vague or missing safe-harbour language get significantly less serious attention, because nobody with a mortgage tests a target that has reserved the right to call the police.

Three related things get confused constantly:

1. Vulnerability Disclosure Policy (VDP): A published channel and a legal promise, with no money attached. Cheap to run and genuinely valuable — it turns “a stranger found something and had no safe way to tell you” into a ticket. What it will not do is generate proactive research. People report what they stumble across; nobody hunts for free.
2. Vulnerability Reward Programme (VRP / bug bounty): A VDP with a price list. Money buys attention, and attention is what surfaces the findings nobody stumbles into.
3. Penetration testing: A contracted team, a fixed window, an agreed scope, and a report at the end. It is the only one of the three that guarantees coverage — a tester will work through every endpoint in scope whether or not any of them is interesting. Bounty hunters go where the payouts are, which means your unglamorous internal admin panel may go years without a single serious look.

These are complements, not substitutes, and treating a bounty programme as a cheaper pentest is the most common way organisations get this wrong. A pentest gives you assurance over a defined scope on a defined date, which is what an auditor, a customer questionnaire, and a compliance framework all want. A bounty programme gives you continuous, unpredictable, deeply skilled coverage of whatever is most attackable. Neither produces the other’s output.

The Bug Bounty Lifecycle

A submission passes through three parties with different incentives: the researcher, who wants it paid at the highest severity; the triage team, usually the platform rather than the customer, whose job is to filter volume; and the engineering team, who did not ask for this ticket and have a sprint already. Most of the friction in bug bounty lives at the second and third handovers.

Strategic Benefits for Organizations

Once a curiosity run by a handful of technology companies, now standard practice across banking, defence, and government.

• Continuous coverage. Two testers for two weeks against several hundred researchers year-round, each bringing a different obsession. Someone out there has spent eighteen months exclusively on OAuth implementation flaws and will find yours in an afternoon. You cannot hire that person; you can pay them for the one finding.
• Pay for results. No valid findings, no invoice. This is the headline and it is also slightly misleading — see below.
• Faster than the attackers. Automated exploitation of newly deployed code is quick, and a permanently open reporting channel occasionally beats it. Occasionally is worth a great deal.
• A visible trust signal. A public programme with clear safe harbour tells customers and regulators that you invite scrutiny rather than fearing it. Increasingly this shows up in procurement questionnaires.

What it actually costs. The bounties are the small line. The real expense is the engineering capacity to fix what comes in — a programme that pays for findings and never ships the patches generates researcher contempt and a documented list of vulnerabilities you knew about, which is a materially worse legal position than not having looked. Add triage, whether you buy it from the platform or staff it, and the duplicate reports, the automated-scanner output submitted as original research, and the perennial argument over whether a self-XSS is worth anything. Run the programme private and invite-only until your remediation pipeline can absorb the volume. Going straight to public with a two-person security team is the classic mistake, and it takes about three weeks to become obvious.

The Bug Hunter’s Toolkit

Everyone runs roughly the same tools. What separates researchers is what they do with the output, and how much of the pipeline they have automated so they can spend their thinking time on the interesting endpoint rather than on collecting a list of subdomains for the ninth time.

1. Interception Proxies — The Command Center

The proxy sits between browser and server, and everything in the request becomes editable. Client-side validation ceases to exist the moment traffic passes through it — which is why “we validate in the JavaScript” is not a control.

• Burp Suite: The standard. Repeater for manual iteration, Intruder for automated variation, and an extension ecosystem that covers most niche needs. Community Edition is usable for learning but rate-limits Intruder to the point of uselessness and drops the scanner entirely; serious hunters buy Professional, and it pays for itself on one medium finding.
• OWASP ZAP: Fully open source, scriptable, and the pragmatic choice for automation and CI. The manual testing experience is less refined, which matters because manual testing is where the findings are.

2. Reconnaissance & Subdomain Enumeration

Recon is where most bounties are actually won. Not the clever payload — the forgotten staging host from a 2019 project that nobody remembers deploying and nobody has patched since.

• Subfinder / Amass: Passive subdomain discovery from DNS aggregators and certificate transparency logs. Certificate transparency is the high-value source: every TLS certificate ever issued is a public log entry, so internal-admin.example.com is discoverable the moment someone requests a certificate for it. Organisations consistently forget this.
• httpx: Probes a list of hosts to see which respond, capturing status codes, titles, and server headers. Turns ten thousand candidate names into forty live things worth a human’s attention.
• Nmap: Host discovery, port scanning, service versioning. Less central for pure web bounty work than the others, essential the moment the scope includes anything non-HTTP.

3. Fuzzing & Content Discovery

Guessing at paths and parameters that exist but are not linked from anywhere.

• ffuf: Fast Go-based fuzzer for directories, parameters, virtual hosts, and anything else you can express as a wordlist. Wordlist choice matters far more than tool choice; SecLists is the common starting point.
• Gobuster: Similar territory, simple and dependable.

A warning that gets people banned: fuzzing is a denial-of-service attack with polite intentions. Default thread counts against a small target’s login endpoint can knock it over, and many programmes cap request rates in their policy. Read that section, then set the rate limit below it.

4. Vulnerability-Specific Tools

• SQLmap: Automates detection and exploitation of SQL injection thoroughly enough that it is often the only way to confirm blind, time-based cases. Also extremely loud, and its default dumping behaviour will happily exfiltrate real customer data — which is a policy breach, not a finding. Stop at proof of the vulnerability.
• Nuclei: YAML-templated scanning across thousands of hosts, ideal for checking a new CVE against a broad scope within hours of publication. Its output is also the single largest source of low-quality duplicate reports on every platform. Verify manually before submitting, always.
• Wireshark: Packet-level analysis. Rarely needed for web work; indispensable for thick clients, mobile applications, and anything speaking a protocol you cannot proxy.

A Roadmap to Getting Started

Expect six to twelve months before a first paid finding if you are starting from a standing start, and expect that finding to be worth about £150. Knowing that in advance is the difference between a hobby you keep and one you quit in month three.

Step 1: Master the Fundamentals

Tools are a shortcut through work you must first be able to do by hand.

• Networking: TCP/IP, DNS, TLS, and HTTP at the protocol level. Know what a Host header is for, and what happens when a server trusts it.
• Web architecture: How applications are actually assembled — REST and GraphQL APIs, single-page apps, cookies and their flags, JWTs, session handling, ORM behaviour. Nearly every serious finding comes from understanding a design decision the developer made, not from a payload.
• Scripting: Python or Go to glue your recon together and iterate on an exploit. JavaScript to read the front end — the bundled JS on a modern app is a map of every API endpoint, including the ones nobody documented.

Step 2: Study the OWASP Top 10

Learn what these look like in source code, not just how to trigger them. A researcher who can predict where a flaw will be — because they know how developers typically get authorisation checks wrong — finds things that payload-throwing never surfaces. Access-control bugs in particular have no signature and no scanner; they are pure reasoning about who should be allowed to do what.

• Cross-Site Scripting (XSS)
• SQL Injection (SQLi)
• Server-Side Request Forgery (SSRF)
• Insecure Direct Object References (IDOR)
• Broken Access Control & Privilege Escalation

Step 3: Practice in Legal Environments

Never touch a live application without written permission. A bounty programme’s published scope is that permission — for the assets it names, and nothing else.

• PortSwigger Web Security Academy: Free, and the best web security training material that exists at any price. Work through it completely before your first live target.
• TryHackMe & Hack The Box: Broader penetration testing, gamified, useful for the non-web fundamentals.
• OWASP WebGoat / Juice Shop: Deliberately vulnerable applications you run locally in Docker, so you can be as destructive as you like.

The gap to be aware of: labs are built to be solvable and every one of them contains a bug. Real targets are frequently well-built, already picked over by fifty researchers, and yield nothing after a full weekend. Learning to spend six hours and find absolutely nothing without concluding you are bad at this is a skill in itself.

Writing a High-Quality Bug Report

The report is the product. The vulnerability is just raw material. A triager working through sixty submissions before lunch will close anything they cannot reproduce in five minutes, and they are right to — the alternative is a queue that never clears. Findings get downgraded, duplicated, or rejected on report quality far more often than on technical merit.

1. A title that states the finding. Vulnerability class, affected endpoint, and parameter: Reflected XSS on /api/v1/search via q parameter. Not “Critical security issue!!!”. The title determines how seriously the rest is read.
2. Impact, in business terms. Not “an attacker can execute JavaScript” but what that gets them — session theft, account takeover, access to another tenant’s records. Triage teams pay for demonstrated consequence, and this is where most researchers leave money behind.
3. A severity rating. CVSS v3.1 or v4.0, with your vector string shown so the reasoning is visible. Resist the temptation to inflate it; a hunter who scores everything Critical is discounted permanently, and that reputation follows you across the platform.
4. A proof of concept that reproduces first time. Exact requests, exact payloads, the account you used, and any state the target needs to be in. Say explicitly if the bug is intermittent. A short screen recording resolves more disputes than three paragraphs of description.
5. Remediation guidance. Parameterised queries, contextual output encoding, a server-side authorisation check at the specific handler. Naming the fix location shortens the path from your report to a paid bounty, because it removes the engineering team’s excuse to defer it.

One thing that quietly matters: prove impact without causing it. Read one record you should not have access to, not the table. Take a screenshot with the sensitive fields masked. Researchers get removed from platforms for exfiltrating production data they were technically able to reach, and “I was demonstrating severity” has never once worked as a defence.

Leading Bug Bounty Platforms

Most organisations do not run intake themselves. Platforms handle researcher identity, tax paperwork, triage, and payment — for a fee, and with the side effect that the person judging your report usually does not work for the company whose product you broke.

• HackerOne: The largest, and the one with the most public programmes. Clients include the US Department of Defense. Volume of researchers cuts both ways: broad coverage, and a duplicate rate on popular targets that will test your patience.
• Bugcrowd: Tightly structured scopes and a researcher ranking system that gates access to the better private programmes.
• Synack: Vetted only — background checks and a technical assessment before you see anything. Far less duplication and more predictable earnings, in exchange for a barrier to entry and considerably less freedom in how you work.
• Intigriti: Europe’s largest, with a good reputation for programme management and for actually mediating when a researcher and a customer disagree.

Giant Independent VRPs

The largest technology companies run their own:

• Google VRP: Deep scope, well-run, and payouts reaching six figures for the most severe classes. Also among the most thoroughly examined attack surfaces on the internet.
• Microsoft Bounty Programs: Windows, Azure, Microsoft 365 and more, with the top awards reserved for critical cloud and hypervisor findings.
• Meta Bug Bounty: Facebook, Instagram, WhatsApp, Quest. Historically generous on account takeover and authentication bypass.

Treat any headline maximum as marketing. Those figures exist and are occasionally paid, almost always for a full remote-code-execution or authentication-bypass chain against a flagship product, found by someone who has specialised in that target for years. The median paid bounty across the industry is a low three-figure sum. Both facts are true; only one of them appears in the press release.

Recommended Books & Resources

Books date faster than the field admits — anything written before 2015 predates the modern single-page app and most of today’s API surface. Read them for the reasoning, not the payloads.

1. The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws by Dafydd Stuttard and Marcus Pinto — the foundational bible of web penetration testing.
2. OWASP Top 10 Web Application: Security Risks by the Open Web Application Security Project.
3. Black Hat Python: Python Programming for Hackers and Pentesters by Justin Seitz.
4. Hacking: The Art of Exploitation: by Jon Erickson.
5. The GWT-RPC Wire Protocol
6. Metasploit Unleashed
7. OWASP Automated Threat Handbook
8. OWASP Testing Guide
9. TR11 Gates — Attacking Oracle Web Apps
10. Complete eBook Library: Download Here
11. A Hacker’s Mind: by Bruce Schneier.

Online Communities & Forums

• HackerOne Hacktivity: Disclosed reports, in full. This is the most underused learning resource in the field — reading how a successful report was written and argued teaches more than any tutorial.
• Bugcrowd Forum: Methodology discussion and platform changes.
• Reddit (r/bugbounty): News, disclosed write-ups, and a steady supply of people asking why their report was marked duplicate.

Expectation vs. Reality: The Hunter’s Mindset

The distribution of bounty earnings is brutally skewed. A small number of full-time researchers earn very well; the large majority of registered accounts have never been paid anything at all. Neither of those facts is a secret, but only the first one gets written about.

• Duplicates. You spend nine hours on a chain, write it up properly, and get “Duplicate — reported 40 days ago”. No payment. This is the single most common experience in bug bounty, and on popular public programmes it is the default outcome for anything findable by ordinary methodology. It is also the strongest argument for going narrow: pick one target, learn it better than anyone else, and stop competing on the endpoints everyone scans.
• Out of scope. The policy lists the assets. Anything else is rejected, however severe, and repeated offences damage your reputation score and your access to private programmes. Read the scope twice before you start, not after you find something.
• Slow triage. Weeks is normal. Months is not unusual. Meanwhile the finding is unpaid, you cannot disclose it, and you cannot report it elsewhere. Assume payment arrives long after you have forgotten the bug.

The people who last treat it as a craft with a long apprenticeship rather than an income stream. Keep a day job while you learn, specialise rather than scanning broadly, read disclosed reports constantly, and measure progress in what you understand rather than what you have been paid. The money follows competence, eventually, with a lag that surprises everyone.