Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference (IDOR) occurs when an application exposes a reference to an internal implementation object (database ID, filename) and fails to verify that the user is authorized to access it. Attackers can manipulate these references to access unauthorized data.

How It Works

The application uses predictable identifiers in URLs or parameters. By changing these values, attackers can access other users' data if no authorization check is performed.

Example

// Viewing your own invoice
GET /invoice?id=1001

// Attack: Change ID to view another user's invoice
GET /invoice?id=1002

// Other examples:
GET /api/users/123/profile       -- change user ID
GET /download?file=report_123.pdf -- change filename
POST /transfer {"from": "my_account", "to": "attacker"}
                                 -- modify account reference

Common Vulnerable Patterns

  • Sequential/predictable IDs in URLs
  • User-controlled file paths
  • Account references in API calls
  • Direct database record IDs

Prevention

  • Implement proper authorization checks on every request
  • Use indirect references (mapping table) instead of direct IDs
  • Use UUIDs instead of sequential IDs
  • Verify ownership at the data layer
  • Apply defense in depth (multiple authorization checks)

PentesterLab Exercises

See Also