$
In 2026, companies are paying strangers on the internet to break into their websites — legally, ethically, and often generously. Apple. Google. Meta. Microsoft. Samsung. Tesla. Every major tech company on earth has an active bug bounty programme. They are actively looking for people exactly like you to find security vulnerabilities they missed. The barrier to entry is not a degree, not a certification, and not a background check. It is demonstrating that you can find and responsibly report a real security vulnerability.
This is the complete, unfiltered, step-by-step guide to bug bounty hunting for beginners — from creating your first HackerOne account to collecting your first bounty payment. Every tool mentioned is free. Every step is explained from first principles. Every example is real.
I am going to show you exactly what I do — from opening Burp Suite to submitting the final report. Not the polished retrospective version. The real workflow, including the dead ends, the N/A reports, and the moment a triage engineer replies with: “This is a valid finding. Triaged.”
📍 What This Guide Will Give You — Specific and Honest
✅ A platform account ready to hunt today
✅ A complete testing toolkit (all free)
✅ A target selected using the right criteria
✅ A recon methodology that finds attack surface
✅ A vulnerability testing workflow (OWASP-based)
✅ A professional report template that gets paid
❌ A guarantee of immediate income (nobody can promise that)
❌ A shortcut that skips the learning curve (there isn’t one)
📋 Complete Step-by-Step Contents
What Bug Bounty Hunting Actually Is — And What It Isn’t
Bug bounty hunting is the practice of finding security vulnerabilities in a company’s digital products — websites, apps, APIs — within the boundaries of a formal written programme, then reporting those vulnerabilities to the company in exchange for a cash reward. It is a multi-million dollar industry in which ordinary individuals earn extraordinary income by doing what security professionals call “authorised penetration testing at scale.”
The word “bounty” comes from the reward. The word “bug” is a colloquial term for a security vulnerability. When you combine them you get: a company offering cash rewards for security vulnerabilities found by external researchers. The reward exists because the cost of a researcher finding a bug is dramatically lower than the cost of a criminal exploiting it.
securityelites.comTHE BUG BOUNTY ECOSYSTEM — HOW IT ALL FITS TOGETHER
🧑💻
YOU
Security Researcher
Find vulnerabilities
🏦
PLATFORM
HackerOne · Bugcrowd
Triage · Payments
🏢
COMPANY
Apple · Google · Meta
Receives & fixes bug
$300M+
Paid to researchers on HackerOne alone
3,000+
Active bug bounty programmes worldwide
$100
Minimum bounty (many programmes)
$2M+
Single largest bounty ever paid (Apple)
The Bug Bounty Ecosystem — You find a vulnerability, report it through a platform (HackerOne or Bugcrowd), the platform triages it, the company verifies and pays. The entire process is formal, legal, and documented. Over $300M has been paid to researchers on HackerOne alone since its founding.
STEP 1
Platform Registration — Where Bug Bounty Hunters Operate
There are two platforms every bug bounty beginner should join immediately: HackerOne and Bugcrowd. These are the two largest and most established platforms — they host programmes from most major tech companies, provide a formal submission and triage system, handle payments, and give you a reputation score that grows with every valid finding. Both are free to join.
1
Register on HackerOne — Complete Your Profile
Go to hackerone.com → Sign Up → Use your real name (companies pay real people, fake names cause payment issues). Complete your profile: add a photo, write a brief bio mentioning your security interests, link your GitHub if you have one. Navigate to Settings → Payments → add your PayPal or bank details. An incomplete profile sends a signal of inexperience to programme owners reviewing your reports.
2
Register on Bugcrowd — Your Second Platform
Go to bugcrowd.com → Join as a Researcher → Complete your profile identically to HackerOne. Bugcrowd hosts different programmes — some of the best beginner-accessible programmes are exclusively on Bugcrowd. Having both accounts gives you access to nearly every public bug bounty programme in the world.
💡 Mr Elite’s Tip — The Reputation Game: Both HackerOne and Bugcrowd have reputation systems. Every valid finding adds reputation points. Higher reputation unlocks private programme invitations — exclusive programmes with less competition and higher payouts. Your reputation is a career asset. Every valid report, even a $100 finding, builds the reputation that eventually gets you into Google’s or Apple’s private programme.
STEP 2
Build Your Bug Bounty Toolkit — Every Tool is Free
The professional bug bounty hunter’s toolkit is surprisingly compact. You need exactly these tools before touching any target. No exceptions, no substitutions for beginners.
securityelites.comBUG BOUNTY STARTER TOOLKIT — EVERY TOOL FREE
B
Burp Suite Community Edition
FREE
ESSENTIAL
The #1 web security testing tool. Intercepts all browser traffic, lets you modify requests, run automated payloads, and analyse responses. Download from portswigger.net/burp/communitydownload
Setup: Proxy → 127.0.0.1:8080 · Firefox + FoxyProxy · Import CA cert
🦊
Firefox + FoxyProxy Extension
FREE
Dedicated browser profile for bug bounty — never mix with personal browsing. FoxyProxy routes all Firefox traffic through Burp Suite with one click. Install Burp’s CA certificate in Firefox to intercept HTTPS traffic.
🔍
Subfinder + Amass
FREE
Subdomain enumeration tools. Discover every subdomain of a target domain. New subdomains = new attack surface = better chance of finding something others missed. Install via: go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
📝
Notion or Obsidian (Notes)
FREE
Underrated but critical. Document every subdomain found, every interesting endpoint, every parameter tested, every finding — regardless of severity. Your notes ARE your methodology. Professional hunters have notes systems going back years.
⚠️
Dedicated Test Accounts — Non-Negotiable
Create 2–3 separate accounts on every target programme using email aliases (e.g. yourname+test1@gmail.com). NEVER test using real user accounts, your personal account, or accounts that contain real data. IDOR testing specifically requires Account A attempting to access Account B’s data — this requires two separate accounts you own.
Bug Bounty Starter Toolkit — All five components are free. Burp Suite Community is the most important single tool. FoxyProxy routes Firefox traffic through Burp. Subfinder discovers attack surface. Notes are your methodology. Dedicated test accounts are a legal requirement, not an option.
STEP 3
Choosing Your First Programme — The Decision That Determines Everything
Programme selection is the most underrated decision in bug bounty. Beginners often pick the biggest names — Google, Apple, Meta — because the payouts are highest. This is exactly backwards. These programmes have the most competition from experienced hunters. The correct strategy for beginners is to find a well-run programme with wide scope and less competition where pattern recognition from your skill level can still find real issues.
Use this exact checklist before committing to any programme:
✅ CHOOSE A PROGRAMME WITH:
Wide scope — multiple subdomains, API, mobile app all in scope
Bounties for low severity — they pay for $100–$500 findings, not just critical
Disclosed reports — read them to understand what’s findable
Fast triage — SLA under 14 days means your reports get reviewed quickly
Safe Harbour clause — legal protection for good-faith research explicitly stated
Active programme — recent reports in the timeline means it’s not abandoned
❌ AVOID AS A BEGINNER:
Google, Apple, Meta — extreme competition, requires advanced skills
Hall of Fame only — no cash, only recognition. Not worth your time yet
Narrow scope — only one subdomain means almost nothing is in scope
No disclosed reports — you can’t learn what’s been found
Private programmes — invitation only, you can’t access these yet
Vague scope documents — if you’re unsure if something is in scope, it’s dangerous to test
💡 The Disclosed Reports Strategy: Before writing a single HTTP request on any target, read every disclosed report in that programme’s HackerOne timeline. Go back at least 12 months. Make a list of every vulnerability type that was found and paid. This tells you: (1) what kind of bugs exist in this codebase, (2) what the triage team considers valid vs N/A, and (3) where other hunters have already looked so you can look elsewhere. This single habit is what separates hunters who earn on month 2 from those still finding nothing at month 12.
STEP 4
Reconnaissance — Map the Target Before You Touch It
Reconnaissance is the intelligence-gathering phase before any testing begins. Professional hunters spend more time on recon than testing. The more thoroughly you understand the target’s surface area, the more likely you are to find the endpoint, parameter, or feature that has been overlooked by both developers and other hunters.
Here is the exact recon methodology I use on every new target, in order:
R1
Subdomain Enumeration
Find every subdomain in scope. Most hunters only test the main domain. Hidden subdomains — staging servers, old API versions, internal tools accidentally made public — are gold for beginners because they receive less security review.
subfinder -d target.com -o subdomains.txt
cat subdomains.txt | httpx -o live_subdomains.txt
R2
Browse the Application — Intercept OFF
With Burp Suite Proxy set to Intercept OFF, browse every page of the target application using your test account. Click every button. Fill in every form. Use every feature. This populates Burp’s HTTP History with the complete application surface — every endpoint, every parameter, every API call made by the browser.
R3
Mine HTTP History for Targets
In Burp Suite → Proxy → HTTP History, filter by: method = POST (form submissions and data modifications), URL contains “id” or “user” or “account” (potential IDOR parameters), status 302 (redirects that might be bypassable). Every interesting request gets sent to Repeater for testing.
R4
Directory and Endpoint Fuzzing
Use Gobuster or ffuf to find hidden paths the application doesn’t link to: admin panels, API documentation, backup files, configuration files, test environments. These are often in scope and often overlooked.
ffuf -u https://target.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302
STEP 5
The Vulnerability Testing Workflow — What to Test and In What Order
Professional bug bounty hunters work from checklists, not intuition. The OWASP Top 10 is your checklist. Work through each category in order of beginner-accessibility. Here is the prioritised testing sequence with Burp Suite workflows for each:
securityelites.comBurp Suite Community — IDOR Testing Workflow
REQUEST (Test Account A — modifying to access Account B)
GET /api/v1/user/profile?id=2849 HTTP/2
Host: target-app.com
Authorization: Bearer eyJhbGci…
Cookie: session=abc123
↑ Our ID is 2850.
We changed it to 2849.
Whose data comes back?
RESPONSE — 200 OK ✓ IDOR CONFIRMED
HTTP/2 200 OK
{
“user_id”: 2849,
“email”: “alice@gmail.com”,
“full_name”: “Alice Johnson”,
“phone”: “+1 555-0124”,
}
✓ Another user’s PII returned — IDOR finding. Begin documentation.
Burp Suite Repeater — IDOR Test. We changed the user ID from our own (2850) to the adjacent value (2849) and received another user’s complete profile including email, full name, and phone number. This is a textbook IDOR finding. The response returning 200 OK with another user’s PII confirms the vulnerability. Begin documentation immediately.
Insecure Direct Object References — Your Most Likely First Finding
In Burp Repeater: take any request with a numeric ID (user_id, order_id, document_id). Send it with your auth. Change the ID by ±1, ±2, and to random numbers. If you receive data not belonging to your test account — IDOR confirmed.
Common locations: /api/user/{id}, /profile?account=X, /orders/{id}, /documents/{id}, invoice downloads
Security Misconfigurations — Easy Wins with Minimal Tooling
Check: /.env, /config.json, /admin, /phpmyadmin, /.git/config, /backup, /api/docs, /actuator (Spring Boot), /swagger-ui.html. Check response headers for missing CSP, X-Frame-Options, HSTS. Check securityheaders.com for automated header analysis.
Tools: browser dev tools + securityheaders.com + ffuf for directory fuzzing
Authentication Flaws — The Path to Account Takeover
Test password reset flow: Does the reset token expire? Can the same token be used twice? Does the reset form reveal whether an email is registered? Decode any JWT token in Decoder — check for weak algorithm. Test session tokens after logout to confirm invalidation.
Tools: Burp Suite Decoder (JWT), Burp Repeater (reset flow), jwt.io
Cross-Site Scripting — High Impact When Found
Inject <script>alert(1)</script> into every text input field, URL parameter, and header reflected in the response. Check search boxes, comment fields, profile fields, error messages. Use Burp Intruder Sniper with an XSS payload list against each parameter.
Stored XSS (affects other users) pays more than Reflected XSS (affects only current user)
STEP 6
Confirming Your Finding — The Pre-Report Checklist
Found something that looks like a vulnerability? Do not submit immediately. The most common reason valid findings get marked N/A or informative — and earn nothing — is an insufficient confirmation process before submission. Run through this checklist before writing a single word of your report:
Pre-Report Confirmation Checklist — Complete Before Submitting
□
Reproducibility: Can you reproduce the finding consistently with fresh test accounts? If it only worked once, it is not ready to report.
□
In-scope: Is the affected endpoint explicitly listed in the programme scope? Not similar — exactly listed. If unclear, check the programme’s FAQ or ask in a support ticket.
□
Not a duplicate: Search the programme’s disclosed reports for the exact same vulnerability class on the same endpoint. Duplicate submissions earn nothing.
□
Impact is real: Can you articulate what a malicious actor could actually do with this vulnerability? “This is an IDOR” is not impact. “This allows any authenticated user to read the private email addresses and phone numbers of every account on the platform” is impact.
□
Screenshots ready: Every step of reproduction is captured in numbered screenshots showing the request and the response, clearly demonstrating the issue.
□
No real data accessed: You used only your own test accounts. No real user’s data was accessed, stored, or viewed beyond confirming the vulnerability exists.
STEP 7
Writing the Report — The Document That Gets You Paid
A great finding with a poor report gets marked informative or N/A. A good finding with an excellent report gets triaged quickly, validated, and paid. Report quality is a learnable skill — and it directly affects your income. Here is the exact template structure that works:
securityelites.comHackerOne — New Report Submission
Bug Bounty Report — The Winning Template
TITLE — FORMAT: [Vulnerability Type] in [Component/Endpoint] allows [Impact]
IDOR in /api/v1/user/profile endpoint allows any authenticated user to view private profile data of any other user
DESCRIPTION — Technical explanation, no jargon, one paragraph
The endpoint /api/v1/user/profile accepts a user ID parameter that is not validated against the authenticated session. By modifying the user_id parameter to any valid integer, an authenticated attacker can retrieve the full profile data of any user on the platform — including email address, phone number, and home address — without any additional authorisation check.
STEPS TO REPRODUCE — Numbered, exact, reproducible from scratch
1. Register two test accounts: attacker@test.com (Account A, ID 2850) and victim@test.com (Account B, ID 2849)
2. Log into Account A and navigate to your profile page
3. Open Burp Suite — capture the GET /api/v1/user/profile?id=2850 request
4. Send to Repeater — change id=2850 to id=2849
5. Click Send — observe: Account B’s full profile data returned in the response including email, phone, and address
6. Severity confirmed: Account A can access any account’s private data by iterating the id parameter
IMPACT — What can an attacker actually do? Who is affected? How many users?
Any authenticated user can enumerate all user accounts on the platform by iterating the user_id parameter sequentially, harvesting email addresses, phone numbers, and physical addresses of all registered users. With [X] million registered users, this constitutes a full platform-wide data breach by a single authenticated attacker. The harvested data can be used for phishing, social engineering, identity theft, and physical security threats.
Bug Bounty Report Template — Four mandatory sections: Title (formula-based), Description (technical but clear), Steps to Reproduce (exact and numbered), Impact (specific users affected, specific data exposed, specific attacker actions enabled). This template has been used in reports across HackerOne, Bugcrowd, and Intigriti — it consistently produces fast triage responses.
Realistic Bug Bounty Earnings — The Honest Data
Every bug bounty guide oversells earnings potential. Here is the reality — including the awkward early months where you earn nothing while building skill:
| Experience Level | Typical Monthly Earnings | What You’re Doing | Realistic Milestone |
|---|
| Months 1–2 | $0 | Learning tools, reading reports, first N/A submissions. This is normal and necessary. | First submission, even if N/A |
| Month 3 | $100–$500 | First valid finding — often a security header or low-severity misconfiguration. | First “Valid” triage response |
| Months 4–6 | $500–$2,000 | Pattern recognition developing. IDOR findings. First $1,000+ report possible. | Consistent monthly income |
| Months 7–12 | $2,000–$8,000 | Multiple programmes. Private invitations starting. More complex findings. | First private programme invitation |
| Year 2+ | $10,000+ | Full-time hunting potential. Top 100 on HackerOne realistic. Critical findings. | Replace full-time income |
The 6 Mistakes That Keep Beginners Earning Zero
1
Targeting Google or Meta in month one
These programmes have 50,000+ active hunters. Every easy finding was found in 2018. Start with less-competed programmes where your beginner skills can actually find something.
2
Submitting before confirming with two test accounts
Every IDOR claim must demonstrate cross-account data access with two accounts you control. “I can see user ID 2849’s data” is meaningless if 2849 is your own account.
3
Writing one-line reports
“Found IDOR at /api/users” earns N/A. The report template in Step 7 exists because triage teams review hundreds of reports. Make theirs easy — they will reward you for it.
4
Testing outside scope
Finding a vulnerability on a subdomain that is explicitly out-of-scope earns nothing and can damage your reputation. Read the scope document. Test only what is listed. When in doubt, do not test.
5
Hunting without a methodology
Randomly clicking around hoping to find something is not hunting — it is tourism. Use the OWASP checklist. Work through vulnerability classes in order. Document every endpoint you test. Methodology produces findings; hoping does not.
6
Quitting after 3 N/A reports
Every successful bug bounty hunter has a folder full of N/A reports. N/A is not failure — it is information. Each N/A teaches you what that programme’s triage team considers out of scope, informative, or duplicate. That knowledge sharpens your next submission.
Your First 90 Days — A Week-by-Week Plan
securityelites.comBUG BOUNTY HUNTING — 90-DAY WEEK-BY-WEEK PLAN
Setup + Learn + Read Disclosed Reports
Register HackerOne + Bugcrowd. Install toolkit. Choose first programme. Read ALL disclosed reports. Complete BB Course Days 1–5 at securityelites.com. Target: zero income, maximum learning
Recon + IDOR Testing + First Submissions
Run subfinder on all in-scope domains. Browse every feature with Burp. Test every numeric parameter for IDOR. Submit your first report even if uncertain. Target: 3+ reports submitted
Security Misconfig + Auth Testing + First Valid
Check security headers. Test password reset flows. Fuzz for hidden admin paths. Your first valid finding is likely in this window. Target: First “Triaged” response + first bounty payment
XSS + Second Programme + Expand Scope
Add XSS testing to your workflow. Join a second programme. Start Burp Intruder for automated parameter fuzzing. Review your N/A reports and learn from each. Target: $500–$1,500 total by Day 90
90-Day Bug Bounty Hunting Plan — Weeks 1–2 are pure setup and learning with zero income expected. First valid finding typically appears in weeks 5–8. By Day 90 with consistent daily practice, $500–$1,500 total earned is a realistic and achievable milestone. The speed of the first finding determines everything that follows.
Everything You Need Is Already Free
You Now Have the Complete Roadmap.
The Only Variable Left Is Whether You Start.
The 60-Day Bug Bounty Course at SecurityElites.com takes everything in this guide and turns it into 60 daily lessons — each one building directly on the last. Day 1 is live right now. Platform setup to first submission, covered step by step.
Frequently Asked Questions – Bug Bounty Hunting for Beginners
How much money can a beginner make from bug bounty hunting?
Months 1–2: typically $0 while building foundational skills. Month 3: first valid finding, $100–$500. Months 4–6: $500–$2,000/month with consistent daily practice. The income curve is non-linear — the first valid finding validates the methodology and dramatically accelerates confidence and subsequent earnings.
What is the best bug bounty platform for beginners?
HackerOne is the best starting platform — largest public programme directory, extensive disclosed report library, active triage teams. Bugcrowd is an excellent second platform. Start with HackerOne, read 10–20 disclosed reports from your chosen programme, and add Bugcrowd after your first valid submission.
What is the easiest vulnerability to find as a beginner?
IDOR (Insecure Direct Object Reference) and security misconfigurations. IDOR requires only Burp Suite basics — change a numeric ID in an API request and check if you receive data from another user’s account. Security misconfigurations can be found with browser developer tools and minimal tooling.
How long does it take to find your first bug bounty?
Most committed daily learners find their first valid finding between 1–3 months. Key factors: daily practice hours, programme selection (wide scope = more surface area), vulnerability focus (IDOR hunters find their first faster than XSS hunters), and report quality (technically valid findings with poor reproduction steps get marked N/A).
Is bug bounty hunting legal?
Yes — within a programme’s defined scope. The programme policy constitutes explicit written authorisation. Stay within scope, use only your own test accounts, do not access real user data, and follow the responsible disclosure timeline. Read the full programme policy before testing any endpoint.
📚 Continue Your Bug Bounty Journey
ME
Mr Elite
Founder, SecurityElites.com | Bug Bounty Hunter | Security Educator
The thing I want you to understand before you close this article is that bug bounty is not a lottery. Every finding has a methodology behind it. Every paid report follows a repeatable process. The IDOR I showed you in Step 5 — changing a number in a URL and receiving someone else’s data — is found every single day by hunters who simply knew to look for it. The entire difference between earning and not earning in bug bounty is whether you have a methodology. You now have one. The rest is repetition.
