Finding Common Bugs

A handful of vulnerability classes pay most bug bounties because they are common and impactful. Master these three first:

• IDOR — accessing other users' data via predictable IDs
• XSS — injecting script into a page
• SSRF — making the server fetch attacker-chosen URLs

This lesson shows how to hunt each one methodically.

Insecure Direct Object Reference (IDOR) happens when an app uses a user-supplied identifier to fetch an object without checking that the user owns it.

Change the ID, access someone else's data. It is an access-control flaw, not an injection.

To find IDOR, create two accounts and compare. Anything that references an object by ID is a candidate.

• Capture a request from account A that fetches A's data
• Replay it with account B's session but A's object ID
• If B sees A's data, that is IDOR

Watch for IDs in URLs, JSON bodies, headers, and even base64/UUID forms.

Cross-Site Scripting (XSS) is injecting JavaScript that runs in another user's browser. Three main types:

• Reflected — payload echoed back in the immediate response
• Stored — payload saved and served to other users (highest impact)
• DOM-based — client-side JS writes attacker input into the DOM unsafely

Inject a unique marker first to see where and how your input is reflected, then craft a payload that fits the context (HTML body, attribute, or script).

Context determines which payload breaks out and executes.

A simple alert(1) proves execution but reviewers want impact. Demonstrate what an attacker could actually steal or do.

• Read a CSRF token or session info accessible to JS
• Show document.domain to prove the origin
• For stored XSS, show it firing in a victim account

Never actually steal real users' sessions, just demonstrate the capability.

SSRF in a bug bounty context means finding a feature that fetches a URL you control. Likely candidates:

• Webhook URLs, callback URLs
• Image/PDF generators that fetch remote resources
• URL preview / link-unfurling features
• Import-from-URL functionality

Point these at internal or metadata endpoints to prove impact.

When the response does not show the fetched content, use an out-of-band server to confirm the target made a request. An interaction callback proves SSRF blind.

Tools like Burp Collaborator or interactsh give you a unique URL that logs hits.

All three bug classes are found by intercepting and tampering with requests. An intercepting proxy is the core tool.

• Burp Suite or OWASP ZAP to capture/modify traffic
• Repeater to replay and tweak single requests
• Intruder/fuzzer to test many IDs or payloads

Learning your proxy deeply pays off more than any single technique.

The biggest bounties come from chaining bugs. A medium-severity bug plus another can become critical.

• SSRF reaching cloud metadata leads to credential theft and account takeover
• IDOR exposing tokens leads to full account compromise
• Stored XSS in an admin panel leads to admin takeover

Always ask: what can this bug be combined with?

These bugs touch real data and real users. Stay ethical:

• Use your own test accounts, do not view real users' data beyond proof
• Avoid stored XSS payloads that could fire for real users, scope them to yourself
• For SSRF, do not pivot deep into internal systems, prove the primitive and stop

Demonstrating impact responsibly keeps you within safe harbor.

You log in as user B, replay a request using B's session but with user A's object ID, and you receive A's private data. Which vulnerability is this?

You learned to hunt the three highest-value bug classes.

• IDOR: compare two accounts, tamper object IDs, check ownership enforcement
• XSS: probe reflection, fit the payload to context, prove real impact
• SSRF: find URL-fetching features, confirm blind cases out-of-band
• Chain bugs for critical impact (e.g. SSRF to cloud metadata)
• Use an intercepting proxy and stay within scope

Next: turning findings into reports that get paid.