📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
← 60-DAY BUG BOUNTY COURSE
DAY 8 OF 60
IDOR BUG BOUNTY HUNTING
🔐
Two test accounts on authorised targets only. All IDOR testing uses two accounts you register yourself on in-scope bug bounty programmes, DVWA, or TryHackMe/HackTheBox. Never test using another real user’s account or data. Never modify, delete, or exfiltrate real user data beyond what is necessary to confirm the vulnerability. Lab: DVWA Labs Hub.
🔓
In Day 7 you learned that the difference between a $200 and a $2,000 XSS payout is the impact demonstration. IDOR takes that principle further — it is the vulnerability class where a beginner with two browser sessions, Burp Suite from Day 5, and the right methodology finds bugs that experienced security teams missed for years.
An IDOR that exposes another user’s private messages is a finding. An IDOR that lets any user download every other user’s invoices is a Critical. An IDOR that lets a regular user call admin-only API endpoints is a programme’s worst nightmare. All three are found the same way: one account tests what another account’s ID gives access to. Day 8 teaches you that systematic process in full.
This lesson covers IDOR end to end — what it is, horizontal versus vertical privilege escalation, where to find object references, the two-account Burp Repeater testing workflow, numeric ID enumeration with Burp Intruder, GUID-based IDOR, API IDOR, blind IDOR, mass assignment, chaining IDOR with other vulnerabilities, and writing the report that converts your finding into the highest possible payout.
📋 What You’ll Master in Day 8
Where to Find Object References
Two-Account Testing Methodology
Burp Repeater & Intruder Workflow
IDOR via HTTP Method Switching
What Is IDOR & Why It Consistently Pays
IDOR — Insecure Direct Object Reference — is a broken access control vulnerability where an application exposes a reference to an internal object (a database record ID, a filename, an account number) and fails to verify that the requesting user is actually authorised to access that specific object. The application checks that you are logged in, but not whose data you are accessing.
IDOR falls under OWASP Top 10 A01:2021 — Broken Access Control, which is the number one web application vulnerability category. It is not a single bug. It is a class of bugs that appears wherever access control checks are missing, inconsistent, or rely on obscurity rather than server-side authorisation.
💰 PAYOUT RANGES
Non-sensitive data: $150–$500
PII / profile data: $500–$2,000
Financial data: $2,000–$10,000
Account takeover: $3,000–$15,000
Admin escalation: $5,000–$30,000+
🎯 WHY IT PAYS WELL
Data exposure to any authenticated user
Scales to affect every account
Often reproducible in one request
Direct, undeniable impact
Represents architecture-level failure
OWASP #1 most critical category
⚡ WHY EASY TO FIND
No special tools beyond Burp Repeater
Two accounts = all you need
No payload crafting required
Works on every tech stack
API endpoints especially vulnerable
Frequently missed in code review
Horizontal vs Vertical IDOR — Know the Difference
Type
What It Means
Severity
HORIZONTAL
Peer-level access
Account B accesses Account A’s data at the same privilege level. Both are regular users. B reads A’s private messages, invoices, orders, medical records, or personal photos. B has no elevated permissions — just access to A’s resources.
Medium–High
VERTICAL
Privilege escalation
A regular user accesses resources or actions that require a higher privilege level. Calling admin-only API endpoints, reading all users’ data, modifying system settings, deleting arbitrary records. Privilege escalation via IDOR is almost always Critical.
High–Critical
─── Horizontal IDOR example ────────────────────────────────────
Account B reads Account A’s invoice (should be forbidden):
GET /api/invoices/10023 HTTP/1.1 # A’s invoice ID
Cookie: session=ACCOUNT_B_TOKEN # B’s session
→ 200 OK {invoice data for Account A} # IDOR confirmed
─── Vertical IDOR (privilege escalation) example ─────────────── # Regular user calls admin endpoint: GET /api/admin/users HTTP/1.1 # admin-only endpoint Cookie: session=REGULAR_USER_TOKEN # no admin role → 200 OK [{all user records returned}] # CRITICAL IDOR
Where to Find Object References — The Complete Map
Every place an application uses a user-controlled value to retrieve a specific record is a candidate for IDOR testing. From Day 5 you have Burp HTTP History cataloguing every request — this is where you find all the object references to test.
🔢 URL PATH PARAMETERS
/api/users/12345
/orders/67890/details
/messages/abc-uuid/read
/download/invoice.pdf
/profile/username/settings
📦 QUERY PARAMETERS
?user_id=12345
?order=67890&action=view
?doc=../../../secret.pdf
?account=ACCT-001
?token=a1b2c3d4e5f6
📬 POST BODY & HEADERS
{“user_id”: “12345”}
{“recipient”: “user@email.com”}
X-User-ID: 12345
{“account_no”: “ACCT-001”}
{“file”: “report_q3.xlsx”}
🍪 COOKIES & TOKENS
Cookie: user_id=12345
JWT payload: “sub”:”12345″
Cookie: account=ACCT-001
Authorization: Bearer [JWT]
Cookie: role=user ← try admin
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)