🎯 Why This Matters

Some vulnerabilities are everywhere if you know where to look. These "quick wins" are accessible to new hunters, pay real bounties, and build your reputation. Focus here first before moving to complex attack chains - you'll learn the applications while earning money.

🔍 What You'll Learn

• IDOR/BOLA - accessing other users' data (and why it happens)
• Open redirects - where they matter and how to demonstrate impact
• Information disclosure - what actually pays bounties
• Subdomain takeover - claiming abandoned resources
• How to chain low-severity bugs into higher impact

🚀 Your First Win

By the end of this chapter, you'll know the vulnerabilities most likely to land you your first bounty - and understand WHY they exist so you can find them consistently.

"Your first bounty doesn't need to be a P1. Start with what's findable."

What Is IDOR and Why Does It Exist?

IDOR (Insecure Direct Object Reference) — also called BOLA (Broken Object Level Authorization) in API security — occurs when an application exposes references to internal objects (like database IDs) and fails to verify that the user has permission to access them.

Why it happens: Developers build features like "view my profile" or "download my invoice." The code checks "is the user logged in?" but forgets to check "does this user OWN this resource?" It's an easy mistake:

# VULNERABLE CODE (simplified example)
def get_invoice(request, invoice_id):
    # Check: Is user logged in? ✓
    if not request.user.is_authenticated:
        return "Please log in"

    # Missing check: Does this user own this invoice? ✗
    invoice = Invoice.objects.get(id=invoice_id)
    return invoice.data  # Returns ANY invoice to ANY logged-in user

# SECURE CODE (what it should look like)
def get_invoice(request, invoice_id):
    if not request.user.is_authenticated:
        return "Please log in"

    # Check: Does this invoice belong to this user? ✓
    invoice = Invoice.objects.get(id=invoice_id, owner=request.user)
    return invoice.data  # Only returns user's own invoices

Why it's so common: Authorization logic has to be implemented for every endpoint. Miss one, and you have an IDOR. In large applications with hundreds of endpoints, developers inevitably miss some. IDOR is consistently in the OWASP Top 10 because it's easy to create and easy to find.

What Is It and Why Does It Matter?

Open Redirect — An application accepts a user-controlled URL and redirects to it without validation. By itself, this seems harmless, but it enables real attacks:

• Phishing: Send victims to trusted-bank.com/login?redirect=evil-site.com. They see the trusted domain, click, and land on a fake login page that steals credentials.
• OAuth Token Theft: If the redirect happens during OAuth login, attackers can steal authentication tokens by redirecting to their server.
• Bypassing Security Controls: Some security tools whitelist the trusted domain but don't validate redirect parameters.

Why programs accept it: Not all programs pay for open redirects. Many require demonstrated impact (chained with OAuth theft, used in actual phishing scenario). Always check the program's policy - some explicitly exclude "unvalidated redirects" without chaining.

Impact demonstration tip: Many programs reject open redirects without proof of impact. In your report, explain the specific attack: "An attacker could use this redirect to steal OAuth tokens during the login flow, leading to account takeover." Or demonstrate a phishing scenario with screenshots.

What Pays vs What Doesn't

Not all information disclosure is created equal. Programs care about information that can be used for further attacks or directly harms users:

Pays Well (High Impact):

• API keys with write access — AWS keys, Stripe keys, cloud credentials
• Database credentials — Even if you can't connect, exposure is critical
• User PII — Leaked user emails, addresses, phone numbers
• Source code — Especially if it contains hardcoded secrets
• Internal authentication tokens — JWT secrets, session signing keys

May Pay (Medium Impact):

• Internal IP addresses — Useful for further attacks
• Debug endpoints — If they expose sensitive data
• Stack traces with sensitive paths — Reveal internal structure

Usually Doesn't Pay (Low/No Impact):

• Software version numbers alone (without known vulnerabilities)
• Generic error messages
• Email addresses that are already public
• "You're using nginx" without any security impact

How Subdomain Takeover Works

Subdomain takeover happens when:

1. A company sets up blog.company.com pointing to Heroku, GitHub Pages, or similar
2. They stop using the service and delete the app, but forget to remove the DNS record
3. The subdomain still points to the service, but no one has claimed that resource
4. An attacker creates an account on the service and claims that resource name
5. Now the attacker controls content on blog.company.com!

Impact: Attackers can serve phishing pages, steal cookies (if subdomain is trusted by parent domain), host malware, and damage reputation - all appearing to come from the legitimate company.

🏆 $500 for IDOR on Invoice Endpoint

The hunter noticed URLs like /api/invoices/12345 when downloading their own invoice. They changed the ID to 12346 and received a different customer's invoice - complete with name, address, and purchase history.

Technique: Changed one number in the URL. Required two test accounts and 5 minutes of testing. The vulnerability was trivial to find but had real impact on customer privacy.

🏆 $300 for Exposed Stripe API Key

Searching through JavaScript bundles, the hunter found a Stripe API key starting with sk_live_. The key had write permissions - an attacker could have created fraudulent charges or accessed customer payment data.

Technique: Browser dev tools → Sources → Search for "sk_live". The key was hardcoded in a webpack bundle. Took 10 minutes to find.

🏆 $1,000 for Open Redirect in OAuth Flow

The OAuth login had a redirect_uri parameter that accepted any URL. The hunter demonstrated that an attacker could craft a link that, after successful login, would redirect the user (and their authentication token) to an attacker-controlled server.

Technique: Identified OAuth flow, tested redirect_uri parameter with external domain. The chain from open redirect → token theft → account takeover elevated this from P4 to P2.

These seem too straightforward. Do they really pay?

Yes. IDOR is consistently the #1 API vulnerability because it's everywhere. Developers have to implement authorization checks for every endpoint - miss one and you have an IDOR. Straightforward bugs with real impact pay real money. Don't overcomplicate your approach - start by looking for obvious issues. As you gain experience, you'll develop an eye for more subtle variations.

What if I can only find low-severity bugs?

Low severity bugs still pay, still build your reputation, and teach you how the application works. Many hunters chain multiple low-severity bugs to create higher impact. An open redirect alone might be P4, but chain it with OAuth token theft and it becomes P2. Finding P4s is how you learn to find P1s.

How do I know if an IDOR is in scope?

Use two accounts you control - never access data belonging to real users. Your test should be: "Can Account A access Account B's data?" where both accounts are yours. If you find an IDOR, report it immediately. Don't enumerate other users' data or download anything beyond what's needed to prove the bug exists.

My open redirect report was closed as "informational." Why?

Many programs don't pay for open redirects without demonstrated impact. In your report, explain the attack scenario: phishing, OAuth token theft, or bypassing security controls. If it's used in an OAuth flow, emphasize the token theft potential. Some programs still won't accept it - check their policy before investing time.