A practical field guide by Sarath G — Cybersecurity Trainer & Consultant

Bug bounty isn't a get-rich-quick scheme. It's a real skill you can start building today.

What to learn first, how to pick a platform — and a program that isn't already picked clean — how to find and report your first real bug, and an honest read on how long it actually takes.

Scroll to begin
30 seconds, no jargon

What bug bounty actually is

Companies pay independent security researchers to find and responsibly report real vulnerabilities in their own systems — legally, with explicit permission. That's the opposite of unauthorized hacking, which is a crime regardless of your intent.

Term 1

In scope

The exact list of domains, apps, and assets a company has given researchers written permission to test. Anything not on that list is off-limits — a policy violation, not a bonus find. This term comes back constantly on this page.

Term 2

Responsible disclosure

Reporting a vulnerability privately to the company first, and giving them time to fix it — instead of publishing it publicly or exploiting it. This is the practice that makes the whole field legal and trusted.

Legal only because of permission. A bug bounty program is a company's explicit, written invitation to test specific systems. That permission — and staying inside the boundaries it sets — is the entire difference between this and unauthorized hacking.
Before you open a single program

What to learn first

A short, honest list. Skipping straight to "finding bugs" without this underneath you is the fastest way to burn out on invalid reports.

0 / 5 checked
Honest mindset note: most people who quit bug bounty quit in the first six months. Patience and consistency matter more than raw talent here — more on this in the reality-check section further down.
Three phases, in order

The learning path

Each phase exists to make the next one survivable. Skipping ahead is the single fastest route to frustration.

1
Phase 1

Foundations

Free, credible resources — no need to pay for anything at this stage.

PortSwigger Web Security Academy — free, the standard starting point TryHackMe — Bug Bounty path HackTheBox Academy
Then learn the OWASP Top 10 categories
01 Injection
02 Broken authentication
03 Sensitive data exposure
04 XXE
05 Broken access control
06 Security misconfiguration
07 XSS
08 Insecure deserialization
09 Known-vulnerable components
10 Insufficient logging & monitoring
2
Phase 2

Practice on legal, safe targets

Before a single real program. This step exists so your first mistakes happen on a legal practice target — not a live scope where a mistake has real consequences.

DVWA bWAPP OWASP WebGoat HackTheBox machines TryHackMe rooms PentesterLab
3
Phase 3

Real targets, in order

Don't start at the right end of this list. Section below explains exactly why.

VDPs Paid public programs Private / invite-only
Currently, as of 2026 — platforms shift over time

Which platform should you start on

Quick answer: start on HackerOne. Add Intigriti or Bugcrowd once you've got your footing — most active researchers end up running two or three platforms at once, not just one.

HackerOne

Start here
Best overall for beginners
  • Largest researcher community — 1.5 million+ researchers from 170 countries
  • Open registration — no invite needed, just sign up with an email
  • Largest volume of active programs, and a transparent reputation system
  • India is the second-largest contributor of researchers — payouts go directly via PayPal or wire transfer, no geographic restriction
Best for: your first platform, full stop.

Bugcrowd

Broadest range of target types
  • Wide variety of targets — web, API, mobile, cloud, IoT
  • Fully managed triage — a dedicated team validates every report first, usually clearer feedback for beginners
  • Uses the VRT (Vulnerability Rating Taxonomy) — a standardized scale for how severe a bug actually is
Best for: once you want a broader mix of target types.

Intigriti

Most beginner-friendly interface
  • Widely considered the most beginner-friendly platform — clean UI, simpler program pages
  • Known for fast triage feedback — you're not left waiting weeks to hear back
  • Europe-based, so it's often overlooked by Indian hunters specifically — which can mean less competition on good programs
Best for: a strong, less crowded second platform.

Open Bug Bounty

Free, for pure practice
  • Free and non-profit — the lowest possible barrier for an absolute first-timer
  • Good for practicing the mechanics of reporting itself, before a paid platform
  • Distinct from the three commercial platforms above — don't expect the same payout structure
Best for: practicing your first report, zero barrier to entry.
Payments to India, no geo-block. HackerOne pays Indian researchers directly via PayPal or wire transfer — there's no rule stopping you from earning on these platforms as an Indian resident.
The correction most beginner guides skip

The real beginner trap isn't the platform. It's the program.

Jumping straight into flagship public programs — Google, Meta, Apple, Tesla, and similar massive-scope names — means competing against thousands of active hunters on programs that are largely picked clean. High duplicate rates and burnout follow. That's the actual source of most beginner frustration, not which platform you picked.

The fix practitioners actually use: start with VDPs (Vulnerability Disclosure Programs). No cash reward, but dramatically less competition — and a real, higher chance of an actual valid first find. That first find builds the reputation and signal that gets you invited to paid private programs later.
10–50names → real room 200+names → saturated

Check a program's Hall of Fame page before committing time. Roughly how many names are listed is a fast, checkable proxy for how picked-over a program already is.

Avoid wide wildcard scopes (e.g. *.company.com) as a first target — the recon alone can eat weeks before real testing even starts. Prefer a smaller, well-defined scope for your first few attempts.
Give one program real, sustained time — not a few hours across many. At least a week of real attention before moving on. Most easy, obvious bugs get found and reported within the first hours after a program launches — arriving late means going deeper than everyone else already checked, not skimming the same surface.
Optional framework, not a universal rule

Some experienced hunters use a "100-hour rule" — capping themselves at roughly 100 hours on any single program before moving on if nothing reportable has turned up. It's specifically there to avoid the sunk-cost trap of endlessly grinding one bloated enterprise scope. Treat it as one practical approach, not gospel.

The actual workflow

How to find your first bug

Four steps, in this order. Testing before you've mapped the target is how most wasted hours happen.

01

Reconnaissance

Map the attack surface first — subdomain enumeration, HTTP probing. Recon comes before testing, not instead of it.

02

Map it manually

Browse it like a real user. Note features, authentication mechanisms, every input field — forms, parameters, headers — and any APIs.

03

Choose what to hunt for

Impact-first, not whatever's easiest to test: auth flaws, access control (IDOR, privilege escalation), injection, business logic (price manipulation, coupon reuse, race conditions).

04

Document as you go

Screenshots, request/response captures, reproduction steps — before you ever start writing the actual report.

The second most important section on this page

How to write a report that doesn't get rejected

Step through it like a template — this is close to what a genuinely good report looks like, field by field.

1 / 7 · Title
Specific and descriptive, never generic
A vague title makes it hard for a triager to quickly assess your report and check for duplicates. Name the specific vulnerable parameter or endpoint, and the impact — not just the bug class.
Bad"XSS in app.example.com" · "IDOR vulnerability"
Good"Reflected XSS via the redirect_to parameter on /login — allows session token theft"
2 / 7 · Reproduction steps
Write for a reader who has never seen the target before
One clear instruction per line — no skipped steps, no assumed context. Mention any prerequisites upfront, e.g. "Requires a test account with admin rights." If the triager has to guess a step, the report stalls.
3 / 7 · Proof of Concept
Enough detail that anyone can reproduce it — not just you
Include screenshots, the actual request/response data, or a short screen recording where it helps. A PoC that only makes sense to the person who found the bug isn't a PoC yet.
4 / 7 · Impact statement
This is where most of the reward decision actually happens
Explain concretely what could go wrong: what data could be exposed, what an attacker could actually do with this. Quantify it where you can. Don't stop at describing the technical mechanism and leave the "so what" unanswered.
5 / 7 · Formatting
Use markdown, headers, and bullet points
A clean, well-organized report gets triaged faster and leaves a better first impression — before the triager has read a single technical detail.
6 / 7 · Tone
Be polite, especially when following up
Most platforms have a "request support" or "ask a scope question" option — use it instead of guessing when you're unsure. A calm, professional tone tends to get faster, more useful responses.
7 / 7 · One bug, one report
Don't split one bug into multiple reports
Reporting the same underlying issue against slightly different parameters on the same endpoint reads as duplicates — and will likely be treated, and paid, as a single finding either way.
The list every rejected report has in common

Common beginner mistakes to avoid

These aren't rare edge cases — they're the same handful of mistakes showing up across nearly every beginner's early reports.

DON'T

Skip the program policy

Not reading the full scope before starting is the single most repeated mistake, across every source on this topic.

DON'T

Test out-of-scope assets

Real risk here is a platform ban or legal exposure — not just a rejected report.

DON'T

Rush to report unverified issues

A lot of "invalid" reports are theoretical problems nobody actually confirmed were exploitable.

DON'T

Skip the duplicate check

Not searching existing reports first wastes time on something someone already found.

DON'T

Scan production without permission

Running automated scanners against a live target without explicit permission can disrupt real service.

DON'T

Chase easy bugs over real impact

Reward and reputation follow real impact — data leaks, account takeover, privilege escalation — not technical novelty.

Read this before you check your first payout

A skill built over months, not a bug found in a weekend

Most people who quit bug bounty quit in the first six months.

Not because they lack ability — because early progress is slow: duplicate reports, invalid findings, programs that go quiet. That's normal, not a sign you're doing it wrong.

If you're wondering about money: the honest, anecdotal pattern from practitioner blogs and community writeups — not verified industry data — looks roughly like this. The first several months are commonly $0 while you're still learning. Consistent income, if it comes at all, tends to build over one to several years, not weeks.

Months 0–6 · mostly $0, learning Year 1–2 · first consistent finds Year 2+ · some build real income

Anecdotal, gathered from practitioner blogs and community writeups — not verified industry statistics. Individual results vary enormously.

This is a skill built over time, same as everything else on this site. No shortcut, no guaranteed outcome. Real people quit constantly — the ones who don't are the ones who eventually see results.

Curated, not exhaustive

Resources worth your time

Free and practitioner-respected only. No paid courses, no products — several surfaced during research and were deliberately left out.

Why this actually matters

This is a skill you build, not a shortcut you take

None of this works as a "learn it this weekend" shortcut — the researchers earning consistently on these platforms got there through real skill-building over time, not luck or a single lucky find. If you want a structured path into this and other cybersecurity domains before you jump into live programs, start with the fundamentals and get hands-on practice first.

Who wrote this

I'm Sarath — a cybersecurity trainer and consultant with 9+ years in the field. I've trained teams at organizations including:

Indian Navy Samsung Electronics IIT Madras Central banks