Bug bounty hunting rewards people who find security flaws in other organisations' systems, but only when the testing is authorised, in scope and reported the way each programme demands, and many newcomers lose reputation, rewards or legal protection by getting those rules wrong. This guide covers the career side: what the work involves day to day, the skills and tools that matter, how platforms judge and rank researchers, the legal boundaries of good-faith research, certifications that genuinely help, and where the role leads. It is written for developers, testers and students considering bounty work, and for security leaders who hire former hunters. The programme-owner side, running a VDP or bounty, is covered in the Bug Bounty and Vulnerability Disclosure Guide and is not repeated here. Platform rules were checked on 8 November 2026 and change often, so always read the current programme brief.
Key takeaways
- Authorisation is the whole job. A programme's scope and rules are what turn testing into permitted research; anything outside them is unauthorised access under laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act 1990.
- Income is irregular and first-to-find. Bugcrowd's standard terms pay the first eligible reporter of a previously unknown issue that triggers a code or configuration change; duplicates usually earn nothing, so treat early bounty work as training, not salary.
- Report quality builds the career. HackerOne's Code of Conduct requires reproducible steps, a proof of concept and accurate severity, and treats repeated severity inflation and unverified AI-generated reports as violations.
- Disclosure needs permission. Both HackerOne and Bugcrowd require programme consent before publishing details, and private programmes must not even be named outside the platform.
- The skills transfer. Web, API and cloud testing, clear writing and impact reasoning lead naturally into penetration testing, application security, product security and vulnerability research roles.
What the role does
A bug bounty hunter is an independent security researcher who tests systems that an organisation has placed in a published programme, reports valid vulnerabilities through the programme's channel and is paid per accepted finding, usually by severity. Most hunters work part time alongside a job; a smaller group work full time across several platforms and private invitations.
| Activity | What it involves | Share of a typical week |
|---|---|---|
| Reading programme briefs | Scope (domains, apps, APIs), exclusions, rate limits, test account rules, disclosure policy, safe harbour statement | Small but essential: done before every new target |
| Reconnaissance within scope | Mapping in-scope hosts, application features, roles and API endpoints; reading public documentation and change logs | Large |
| Manual testing | Access control, authentication and session logic, business logic, injection classes, server-side request forgery, misconfigured cloud storage | Largest |
| Writing reports | Reproduction steps, proof of concept, impact, severity with rationale, suggested fix | Significant |
| Triage communication | Answering questions, retesting fixes, requesting disclosure | Ongoing |
Business model realities:
- First to find wins: rewards go to the first eligible reporter, and only for issues that lead to a change. Popular public programmes attract many duplicates.
- Rewards vary by impact: Bugcrowd's terms say amounts depend on business impact, severity and creativity, and may be paid in money, points, CPE credits or swag. Monetary rewards require the reporter to be 18 or over (or the local age of majority), and hunters are responsible for their own taxes.
- Deadlines exist: Bugcrowd forfeits unclaimed rewards after six months, so payment and identity verification need attention.
- Private programmes: platforms invite researchers with a track record to private programmes with fewer competitors. A clean conduct record and accurate reports are what earn invitations.
Legal boundaries and rules of engagement
Good faith is defined, not assumed. The US Department of Justice policy of 19 May 2022 directs federal prosecutors that good-faith security research should not be charged under the CFAA, and defines it as accessing a computer solely for good-faith testing, investigation and/or correction of a security flaw, carried out to avoid harm, with the information used primarily to promote security. The same release says finding vulnerabilities in order to extort their owners is not good faith. HackerOne's Gold Standard Safe Harbor uses the same definition and says research not conducted in good faith is not covered. This is prosecutorial policy and a platform commitment, not a licence: it does not bind other countries or civil claims, so the programme's written scope is your real protection. See the Security Research Legal Safe Harbours Guide and the Computer Misuse and Anti-Hacking Laws Guide.
| Boundary | Rule (source) | Practical meaning |
|---|---|---|
| Scope | Adopting safe harbour does not change scope, which stays limited to assets the programme explicitly includes (HackerOne safe harbour FAQ) | A subdomain that looks related but is not listed is out of scope; ask first |
| Test intensity | No unauthorised tests, no going beyond what is needed to show impact, no altering production data, no denial of service (HackerOne Code of Conduct) | Stop at proof of access; use your own test accounts |
| High-risk methods | Social engineering, physical testing and noisy attacks need explicit programme authorisation (HackerOne Code of Conduct) | Assume excluded unless the brief says otherwise |
| Data | Access only what is needed; do not dump databases; publishing personal data requires the individual's explicit consent (HackerOne Code of Conduct) | Record minimal evidence, then delete anything accessed by accident |
| Disclosure | Explicit programme approval before publishing; respect timelines even after a fix (HackerOne); confidential by default unless consent or brief allows (Bugcrowd) | Use the platform's disclosure request process for write-ups |
| Extortion | Zero tolerance; first offence is a permanent ban and authorities may be informed (HackerOne Code of Conduct) | Never tie disclosure to payment |
| Accounts | One submitting account; no sharing, selling or reputation farming (HackerOne Code of Conduct) | Ban evasion leads to permanent bans |
| Automation and AI | Hackbots must follow programme rules and a human must validate every finding before submission (HackerOne Code of Conduct) | Respect rate limits; verify every AI-assisted claim |
Credentials found during testing deserve special care. Exposed API keys, cloud access keys and tokens are common valid findings, but using a found key beyond confirming that it is live (for example listing data with it) usually breaks the "minimum needed" rule. Report the location and type, and let the owner revoke and rotate it. The Leaked secret breaches guide shows why these leaks matter.
Core skills and tools
- Web and HTTP fundamentals: request and response structure, cookies and their security attributes, CORS, caching, redirects and how browsers enforce the same-origin policy.
- Authentication and authorisation logic: most high-value findings are broken access control: horizontal and vertical privilege escalation, insecure direct object references, flawed password reset and OAuth flows. The OWASP API Top 10 API1 Broken Object Level Authorization Guide covers the most common API class.
- Testing methodology: the OWASP Web Security Testing Guide gives a systematic checklist so coverage does not depend on luck. See the OWASP WSTG Guide.
- Intercepting proxy: Burp Suite or an equivalent proxy is the central tool for observing and replaying requests in authorised testing. See the Burp Suite for Authorised Web Testing Guide.
- Scripting: Python or similar for parsing responses, automating in-scope enumeration within rate limits and building clean proofs of concept.
- Cloud and mobile: object storage permissions, identity tokens in mobile apps, metadata service exposure through server-side request forgery.
- Severity reasoning: platforms use scales such as Bugcrowd's Vulnerability Rating Taxonomy (P1 Critical to P5 Informational, with some entries marked Varies) and FIRST's CVSS v4.0 (Base, Threat, Environmental and Supplemental metric groups). Rate honestly and explain the business impact.
- Writing: a triager should reproduce your finding in minutes. Title, affected asset, steps, proof of concept, impact, severity and fix, in that order.
What a strong report contains
| Element | Good practice | Common weakness |
|---|---|---|
| Title | Vulnerability class, asset and impact in one line | Vague titles such as "XSS found" |
| Steps to reproduce | Numbered, with exact requests and test account roles | Missing preconditions |
| Proof of concept | Minimal, non-destructive, uses your own data | Real user data in screenshots |
| Impact | What an attacker could realistically do, and to whom | Theoretical worst case with no path |
| Severity | Mapped to the programme's scale with rationale | Inflated rating, a Code of Conduct issue on HackerOne |
| Remediation | Specific fix and where it belongs | None |
Routes into the role
- Build fundamentals on legal labs. Use deliberately vulnerable training platforms, capture the flag events and vendor academies rather than live sites. See the Cyber Ranges, CTFs and Hands-On Training Guide.
- Start with vulnerability disclosure programmes. VDPs pay nothing but are low competition and teach report writing and triage communication. Many platforms let VDP findings count towards reputation.
- Pick one platform and one niche. Depth in one target type (for example OAuth flows or GraphQL APIs) beats shallow scanning of many programmes.
- Keep a methodology log. Record what you tested on each programme, so you can return after feature releases, which is where new bugs appear.
- Publish permitted write-ups. With programme approval, public write-ups become a portfolio that employers read.
- Move into private programmes. Invitations follow a record of valid, well-written, in-scope reports and a clean conduct history.
Coming from development: developers already understand frameworks, authentication libraries and APIs, and often find logic flaws faster than generalists. Coming from IT operations: cloud and identity configuration knowledge transfers well to storage, token and misconfiguration findings. For broader options see the Cybersecurity Careers Guide.
Certifications that help
No certification is required to join a bounty platform, and results speak loudest. Certifications help most when moving from bounties into employed roles, where hiring managers and procurement teams look for them. Practical, exam-by-exercise certifications are the closest match to bounty work.
| Certification | Relevance to bounty work | Detail |
|---|---|---|
| PortSwigger Burp Suite Certified Practitioner (BSCP) | Web vulnerability depth and practical Burp skills; PortSwigger says it is valid for five years and requires an active Burp Suite Professional subscription to sit | PortSwigger BSCP |
| OffSec OSWA | Web application attacks, black-box | OffSec OSWA |
| OffSec OSWE | White-box web exploitation and source review | OSEP and OSWE Certification Guide |
| GIAC GWAPT | Web application penetration testing methodology | GIAC GWAPT |
| OSCP | Broad infrastructure testing; useful for moving into penetration testing | OSCP Certification Guide |
| CREST certifications | Recognised for UK and international penetration testing employment | CREST Certifications |
Bugcrowd notes that valid submissions can count towards ISC2 CPE credits, which helps hunters who already hold ISC2 certifications keep them current.
Progression
- Penetration tester or red team: structured, contracted testing with broader scope. See the Penetration Tester Career Guide.
- Application security engineer: fixing the classes of bugs you used to find, threat modelling and secure code review. See the Application Security Engineer Career Guide.
- Vulnerability researcher: deeper work on products and protocols, CVE publication and coordinated disclosure. See the Cybersecurity Researcher Career Guide.
- Triage and programme management: platforms and large companies hire experienced hunters to validate reports and run programmes, where knowledge of the hunter side is directly useful.
- Full-time independent hunter: possible for a minority; plan for irregular income, tax registration and the risk that a programme closes or changes scope.
What employers look for: a public record of accepted reports or approved write-ups, evidence of staying in scope, clear writing, and an understanding of remediation, not just exploitation. A conduct violation, especially uncoordinated disclosure, can follow a researcher into hiring conversations.
Practitioner checklist
- Read the full programme brief, scope list, exclusions and safe harbour statement before sending a single request.
- Confirm every target host is explicitly listed in scope; ask the programme when unsure.
- Use only your own or programme-supplied test accounts and respect stated rate limits.
- Stop at the minimum evidence needed to show impact; never retain personal data.
- Report found credentials by location and type without exercising them further.
- Write reports with exact steps, a non-destructive proof of concept, honest severity and a fix.
- Verify every AI-assisted or tool-generated finding personally before submitting.
- Request disclosure through the platform process and never mention private programmes publicly.
- Track rewards, identity verification, tax obligations and claim deadlines.
- Keep a methodology log per programme and revisit after product releases.
Standards and references
- US Department of Justice: New Policy for Charging Cases under the Computer Fraud and Abuse Act
- HackerOne: Code of Conduct
- HackerOne Help Center: Safe Harbor Overview and FAQ
- Bugcrowd: Standard Disclosure Terms
- Bugcrowd: Vulnerability Rating Taxonomy
- FIRST: Common Vulnerability Scoring System v4.0
- PortSwigger: Burp Suite Certified Practitioner
Related NHI Mgmt Group resources: Bug Bounty and Vulnerability Disclosure Guide · Penetration Tester Career Guide · Security Research Legal Safe Harbours Guide · Web Application Security Testing Guide