Post cover image

September 19, 2026

Beginner-Friendly Vulnerabilities: IDOR, XSS, and Open Redirects

When I started my bug bounty journey, I made the same mistake most beginners do: I chased the “cool” stuff. I read writeups about…

By Sukhveer Singh

4 min read

When I started my bug bounty journey, I made the same mistake most beginners do: I chased the "cool" stuff. I read writeups about deserialization RCEs, SSRF chains, and race conditions — and understood almost none of it.

Then a mentor told me something I still repeat to every student at Bugitrix:

"Stop chasing elite bugs. Master the beginner bugs first. They pay more often than you think."

He was right. Three of the first valid reports I ever got paid for were an IDOR, a reflected XSS, and an open redirect. No fancy tooling. No zero-days. Just understanding how the application was supposed to behave — and breaking it.

In this article, I'll walk you through these three beginner-friendly bugs the way I actually hunt them in the field.

For educational purposes only. Only test systems you own or have permission to test.

Why These Three Bugs Matter (More Than You Think)

Before we touch payloads, understand the real-world impact:

  • IDOR (Insecure Direct Object Reference) is a broken access control issue — and broken access control has held the #1 spot in the OWASP Top 10. One IDOR can expose millions of user records.
  • XSS (Cross-Site Scripting) lets attackers run JavaScript in a victim's browser — stealing session cookies, tokens, or performing actions as the user. It's been a top web security issue for two decades for a reason.
  • Open Redirect looks harmless, but it's a phishing powerhouse. Attackers weaponize your trusted domain to send victims to malware or credential-harvesting pages.

Bug bounty programs pay for these because they're everywhere. APIs, dashboards, password reset flows, login pages — beginner bugs hide in all of them. And as a pentester, these are the first things I test on any engagement.

1. IDOR — When Changing a Number Changes Everything

IDOR happens when an application uses user-supplied input to access objects directly — without checking whether you are allowed to access them.

Classic example:

text

GET /api/v1/users/1337/invoices/5501 HTTP/1.1
Host: target.com
Authorization: Bearer <your_token>

Now ask yourself: What if I change 5501 to 5500?

If you get someone else's invoice, that's IDOR.

How I Test for IDOR

  1. Create two accounts (Account A and Account B). This is non-negotiable. You need a victim you control.
  2. Map every endpoint that takes an ID: user_id, invoice_id, order_id, file_id, UUIDs, etc.
  3. Intercept requests in Burp Suite and swap IDs between accounts.
  4. Test every HTTP method — GET, POST, PUT, DELETE, PATCH. Read-only IDORs are common, but delete/update IDORs are devastating.
  5. Don't ignore UUIDs. Predictable UUIDs (v1, timestamps) can be brute-forced or leaked elsewhere.

Common Pitfalls

  • Testing only the UI. The frontend may hide the button, but the API endpoint still works. Always test the raw request.
  • Giving up after a 403. Try the ID in a different parameter, a different endpoint, or with X-Original-URL style header tricks.
  • Forgetting horizontal vs. vertical. Horizontal = same role, different user. Vertical = escalating to admin. Test both.

Example payloads to try in parameters:

text

id=1337 → id=1336
user=me → user=admin
account_id=1001 → account_id=1000

2. XSS — Making the Browser Dance

Cross-Site Scripting happens when user input is reflected or stored in a page without proper sanitization, letting an attacker execute JavaScript in a victim's browser.

There are three flavors:

  • Reflected XSS — payload bounces off the server immediately (search pages, error messages).
  • Stored XSS — payload is saved and served to other users (comments, profiles).
  • DOM-based XSS — client-side JavaScript writes user input into the DOM unsafely.

My Testing Workflow

Step 1: Find reflection points. Search boxes, URL parameters, error messages, headers like User-Agent and Referer.

Step 2: Fire a canary.

text

<script>alert(1)</script>
"><img src=x onerror=alert(1)>
'"><svg onload=alert(1)>

Step 3: If filtered, get creative. Encoding, case variation, event handlers:

text

<ScRiPt>alert(1)</ScRiPt>
<img src=x onerror=alert(document.domain)>
javascript:alert(1)

Step 4: Check the DOM. Open DevTools and trace location.hash, document.write, innerHTML.

A Real Story

I once found stored XSS in a "bio" field. alert(1) was blocked, but <svg onload=confirm(document.cookie)> sailed through — the filter only blocked <script>. I reported it, it got triaged, and it paid. The lesson? Filters lie. Test variations.

Common Pitfalls

  • Only testing alert(1). Modern programs want impact — use alert(document.domain) to prove it executes in the target's origin.
  • Ignoring self-XSS. If it only fires for you, it's usually out of scope unless you can chain it with CSRF.
  • Skipping DOM XSS. View source won't show it. Use the browser's inspector.

3. Open Redirect — The Quiet Phishing Enabler

An open redirect occurs when an app takes a URL parameter and redirects users to it without validation.

Example:

text

https://target.com/login?next=https://evil.com

If that redirects to evil.com, it's open.

Why It Matters

Alone, it's low severity. But attackers use it for:

  • Phishing with a trusted domain in the link
  • Bypassing OAuth allowlists
  • Chaining with SSRF for internal access

How I Test It

Look for parameters like:

text

?next=  ?url=  ?redirect=  ?return=  ?dest=  ?continue=  ?callback=

Then try:

text

?next=https://evil.com
?next=//evil.com
?next=https://target.com.evil.com
?next=/\evil.com
?next=https://target.com@evil.com

Bypass techniques when blocked:

text

?next=hTTps://evil.com
?next=https://evil.com%2f%2f
?next=//evil%2ecom

Common Pitfalls

  • Assuming // is blocked. Test /, //, and URL-encoded variants.
  • Not checking redirects in JS. Many SPAs handle redirects client-side with window.location.
  • Stopping at the first redirect. Chain it — a redirect + OAuth flow + XSS = critical.

Defender's Perspective: How to Fix These

As a pentester, I always include fixes in my reports:

For IDOR:

  • Enforce server-side authorization on every object access.
  • Use indirect references (mapped IDs per session) where possible.
  • Log and alert on anomalous ID access patterns.

For XSS:

  • Context-aware output encoding (HTML, JS, attribute, URL).
  • Use Content Security Policy (CSP) as defense-in-depth.
  • Sanitize rich text with libraries like DOMPurify.

For Open Redirect:

  • Use an allowlist of permitted redirect destinations.
  • Never reflect user input directly into Location headers.
  • Warn users on external redirects.

http

# Bad
Location: https://evil.com
# Good
Location: /dashboard

Key Takeaways

  • IDOR, XSS, and open redirect are beginner-friendly but high-impact. Don't underestimate them.
  • Always test with two accounts. You can't prove IDOR without a controlled victim.
  • Filters are suggestions, not walls. Encode, mutate, and bypass.
  • Read the raw request. The UI hides more than you think.
  • Chain bugs for bigger impact. Open redirect + OAuth + XSS = critical.
  • Report with clear impact and remediation. Programs love hunters who think like defenders.
  • Practice daily. TryHackMe, PortSwigger Academy, and real bug bounty programs are your gym.

Let's Keep Learning Together

If this helped you, follow my work — I post regularly on bug bounty, web security, and ethical hacking.

Found this useful? Share it with a fellow hunter who's just starting out. And if you're learning pentesting seriously, check out Bugitrix — where we teach you to break things the right way.

For educational purposes only. Only test systems you own or have permission to test.

Hack to learn. Don't learn to hack. 🛡️ — Sukhveer Singh