Bug Bounty Basics: Hack Legally and Get Paid (Beginner’s Playbook)

What a bug bounty is (and isn’t)

A bug bounty is a company’s formal invite to security researchers: test specific assets under specific rules, report security flaws responsibly, and possibly earn a reward. It’s not “free-for-all hacking,” and it’s not permission to test anything outside the posted scope. Programs publish a policy, scope, exclusions, and disclosure terms; your job is to operate inside those guardrails.

Shortcut to staying safe: If it’s not explicitly in scope, it’s out of scope. Ask before you test.

Scope is your contract

Scope tells you what you can test, how you can test it, and what is off-limits (PII scraping, social engineering, DDoS, physical access, rate-limit abuse, etc.). Breaking scope can get you banned—or worse. Read it twice, then build your test plan around it.

• Assets: domains, apps, APIs, mobile packages, cloud resources.
• Exclusions: third-party services, marketing tools, corporate email, anything not owned.
• Safe harbor: many programs commit to good-faith legal protection if you follow the rules.

Read example policies on HackerOne and Bugcrowd. Also see OWASP for vulnerability categories you’ll encounter.

Where beginners should start

Rules of engagement (that keep you welcome)

• Permission: Only test assets listed as in-scope. When unsure, ask in the program’s Q&A.
• Non-destructive: No DDoS, spam, or data destruction. Probing ≠ harming.
• Minimal data: Prove impact with the least data possible; redact PII in screenshots.
• Rate limiting: Respect program rate limits and business hours if specified.
• Disclosure: Follow the program’s disclosure policy—never publicize before permission.

Evidence wins: how to write reports that get accepted

Triage teams prioritize clear, reproducible, minimal-noise reports. Your template should make verification trivial.

1. Title: Concise vulnerability + affected asset (e.g., “Stored XSS on /profile reflects to admin”).
2. Summary: One paragraph of what, where, why it matters.
3. Impact: Business risk (account takeover, data exposure, privilege escalation). Map to CVSS where helpful.
4. Steps to reproduce: Numbered, deterministic, least permissions required.
5. Proof: Sanitized screenshots/video; logs; request/response snippets (redacted).
6. Scope compliance: One line confirming testing stayed within rules.
7. Remediation suggestions: Practical, vendor-agnostic mitigations.

For a portfolio angle, see my post From Home Lab to Job-Ready on turning reports into hireable artifacts.

How to pick your first programs

• Fit to strengths: If you’re strong in web, prefer API/web app scopes over mobile/IoT.
• Signal-to-noise: New or niche programs often have fewer duplicate reports.
• Policy quality: Detailed scope + safe harbor + clear exclusions = better experience.
• Public kudos: Leaderboards and disclosed reports help you learn program expectations.

Browse programs on HackerOne Directory and Bugcrowd Program List.

A clean, lawful workflow

1. Read the policy. List assets, methods allowed, and exclusions.
2. Plan tests. Choose low-risk, permitted techniques first. Keep notes for chain-of-custody.
3. Collect evidence. Use screenshots and request logs; avoid downloading data you don’t need.
4. Write and submit. Use the program template; keep it reproducible and scoped.
5. Respond to triage. Be professional, supply minimal additional data, and accept duplicate/NA decisions gracefully.

If you’re new to testing safely, build reps in a lab first: Nmap Tutorial and Metasploitable & DVWA Setup.

Ethics, disclosure, and staying welcome

• Coordinated disclosure: Follow timelines and never post PoC publicly without explicit approval.
• No account trading/sharing: One identity, one researcher. Keep it clean.
• Respect availability: Don’t stress production with heavy scanning or automation if the rules limit it.

Read vendor policies like Google’s VRP and high-quality writeups on The Daily Swig to calibrate tone and depth.

Common beginner pitfalls (and fixes)

• Scanning out of scope: Fix: whitelist only the assets listed; block everything else in your tooling.
• Submitting noise: Fix: reproduce twice, provide a single clean PoC, and explain impact.
• PII exposure in screenshots: Fix: redact aggressively; share only what’s required.
• Arguing duplicates: Fix: learn from them. Duplicates teach timing and triage expectations.

Quickstart ladder (4 weeks)

1. Week 1: Web basics at PortSwigger; one recap post.
2. Week 2: Juice Shop: 5 challenges → 1 polished writeup.
3. Week 3: Pick a VDP with clear safe harbor; submit 1 high-quality report.
4. Week 4: Join a small bounty program; focus on one asset and write one excellent, scoped report.

Authoritative references

• HackerOne — Official
• Bugcrowd — Official
• PortSwigger Web Security Academy
• OWASP Juice Shop
• FIRST CVSS

Where to go next

Keep your practice legal and structured: Safe Hacking Practice, Nmap Tutorial, Metasploitable & DVWA Setup, and From Home Lab to Job-Ready.