The first bug bounty mistake is not missing an SQL injection. It is testing the wrong target, ignoring the scope, sending a vague report, and wondering why the triager closed it as informative. Bug bounty is not random hacking for cash. It is authorized security research inside rules defined by a program owner.
If you are new, the goal is not to become famous in your first week. The goal is to learn how programs work, avoid causing damage, build a repeatable methodology, and submit one clear, reproducible, valid report. Everything else comes from repetition.
What Bug Bounty Actually Is
A bug bounty program lets security researchers report vulnerabilities in approved assets. If the report is valid, in scope, and impactful, the organization may pay a bounty, issue reputation points, or acknowledge the researcher. Some programs are public. Some are private invitation-only programs. Some are vulnerability disclosure programs with no payment.
Bug bounty in one workflow: 1. Read the program policy 2. Confirm the asset is in scope 3. Test safely 4. Prove business/security impact 5. Write clear reproduction steps 6. Submit evidence 7. Respond to triage questions 8. Learn from duplicates and invalids
The permission boundary is everything. If the policy says no denial-of-service, no social engineering, no physical attacks, no employee targeting, no automated destructive testing, or no production data access, respect it. A bug bounty program is not a blank check.
Major Bug Bounty Platforms
The biggest platforms differ in community, program types, reputation systems, private invitations, and regional strength. Start with one or two platforms instead of creating accounts everywhere and losing track of your work.
Common platforms to know: HackerOne: Large public/private program marketplace, reputation system, many enterprise programs. Bugcrowd: Crowdsourced security platform with public programs, private programs, and VDPs. Intigriti: Strong European presence, public and private bug bounty programs. YesWeHack: European/global platform with public and private programs and VDPs. Synack: More curated researcher model; access requires vetting. Open Bug Bounty: Coordinated disclosure platform, often focused on web vulnerabilities. Program-owned portals: Many companies run their own security.txt, VDP, or private submission portal.
For beginners, public VDPs are good for learning report writing, but they may not pay. Paid public programs are more competitive. Private programs can be better, but invitations usually require a track record.
Choosing Your First Program
Do not start with the largest, most hunted company on the internet. Choose a program with clear scope, beginner-friendly policy, responsive triage, realistic assets, and technologies you understand. Avoid programs where every obvious bug has already been found unless your goal is pure practice.
Beginner program checklist: [ ] Clear in-scope domains or apps [ ] Clear out-of-scope list [ ] Safe testing rules [ ] Recent resolved reports or active triage [ ] Web app you can understand [ ] No fragile production-only workflow [ ] Bounties or reputation if that matters to you [ ] No requirement for advanced mobile/cloud/reversing skills
Read the policy twice. Then create a small target list. Most valid beginner findings come from careful testing of a small surface, not scanning thousands of subdomains with no plan.
Your First Recon Workflow
Recon should answer three questions: what assets are in scope, what technologies are running, and where user-controlled input reaches sensitive behavior. Keep it lightweight and respectful. Do not hammer production with aggressive scans.
# Passive subdomain discovery subfinder -d example.com -silent -o subs.txt assetfinder --subs-only example.com >> subs.txt sort -u subs.txt -o subs.txt # Probe for live web hosts httpx -l subs.txt -title -tech-detect -status-code -follow-redirects -o live.txt # Screenshot triage gowitness file -f live.txt --disable-db # Content discovery on one approved target ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \ -u https://app.example.com/FUZZ -ic -c -rate 50 # Parameter discovery, carefully katana -u https://app.example.com -d 2 -silent -o urls.txt grep '?' urls.txt | sort -u > urls-with-params.txt
Always respect rate limits and program rules. If the policy restricts automated scanning, do not use aggressive discovery tools. Manual browsing with Burp Community is often enough for your first findings.
Beginner Bug Classes Worth Learning
Beginners often chase exotic bugs too early. Learn the core web vulnerabilities first. They still appear, and they teach the logic of impact.
Good beginner bug classes: - IDOR / broken object level authorization - Stored and reflected XSS - Open redirect with real impact - Broken access control - Sensitive data exposure - Account takeover logic flaws - Password reset weaknesses - Business logic bugs - File upload mistakes - Misconfigured cloud storage - Exposed admin panels - CORS misconfiguration with impact
IDOR is the classic first serious bug because it does not require fancy tooling. You need two accounts, a proxy, and patience. If Account A can change an ID and read or modify Account B’s data, you may have a valid authorization issue.
IDOR test pattern: 1. Create Account A and Account B 2. Log in as Account A 3. Capture a request in Burp 4. Find IDs in the URL, JSON body, or GraphQL variables 5. Replace Account A's ID with Account B's ID 6. Send the request 7. Confirm whether Account B's data is exposed or modified 8. Document exact impact
Example: A Good Bug Bounty Report
A good report is short, reproducible, and impact-focused. Triage teams do not need a novel. They need proof, steps, affected endpoint, impact, and remediation advice.
Title:
IDOR allows any user to download another user's invoice PDF
Summary:
The /api/invoices/{invoice_id}/download endpoint does not verify that the
authenticated user owns the requested invoice. A low-privileged user can
change the invoice_id and download invoices belonging to other accounts.
Affected endpoint:
GET https://app.example.com/api/invoices/INV-10492/download
Steps to reproduce:
1. Create two accounts: attacker@example.com and victim@example.com
2. Log in as victim and create an invoice
3. Record the victim invoice ID: INV-10492
4. Log out and log in as attacker
5. Send this request:
GET /api/invoices/INV-10492/download
6. Observe that the victim's PDF invoice is returned
Impact:
An attacker can access invoices containing customer names, addresses,
line items, billing history, and tax information.
Evidence:
Attach request/response screenshots with sensitive values redacted.
Remediation:
Enforce object-level authorization server-side. The endpoint should verify
that the authenticated user owns the invoice_id before returning the PDF.
Notice what this report does not do: it does not exaggerate, spam screenshots, insult the program, or dump unnecessary personal data. It proves the bug cleanly.
What Not To Do
Avoid these beginner mistakes: - Testing out-of-scope assets - Running destructive scanners - Reporting missing headers with no impact - Submitting vague "XSS possible" claims - Accessing or downloading unnecessary user data - Testing production payment flows without permission - Social engineering employees - Reporting the same issue repeatedly after closure - Ignoring triager questions - Asking for bounty before proving impact
A 30-Day Starter Plan
Week 1: - Learn HTTP, cookies, sessions, Burp Community - Read 20 public disclosed reports - Practice IDOR and XSS in PortSwigger Web Security Academy Week 2: - Pick one platform and one beginner-friendly program - Build a small in-scope asset list - Manually browse every feature - Map roles, objects, and permissions Week 3: - Test IDOR, access control, file upload, reset flows - Write draft reports even for invalid findings - Compare your evidence to public reports Week 4: - Submit only high-confidence findings - Respond professionally to triage - Track duplicates and lessons learned - Improve your checklist
Final Mindset
Bug bounty rewards consistency more than drama. Your first valid report may be small. That is fine. Learn how to stay in scope, test safely, explain impact, and write clean reports. The hunters who survive are not the loudest; they are the ones who keep improving their methodology.
Sources Checked
This guide was aligned with current public platform information from HackerOne, Bugcrowd, Intigriti, YesWeHack, Synack, Open Bug Bounty, and common vulnerability disclosure practices as of May 2026. Always read each program’s policy before testing.