IDOR | Saikumar Infosec

🧠 Description

What is IDOR/BOLA?

Insecure Direct Object Reference (IDOR) occurs when an application exposes internal object references (like database IDs) without proper authorization checks. Attackers can manipulate these references to access unauthorized data.

IDOR allows attackers to:

Access other users' data (horizontal privilege escalation)
Access admin data (vertical privilege escalation)
Modify or delete other users' data
Access sensitive files

🏷️ Classification

Type: Insecure Direct Object Reference (CWE-639) / Broken Object Level Authorization (BOLA)
OWASP: A01:2021 - Broken Access Control
Subtypes: Horizontal IDOR, Vertical IDOR, Path-Based IDOR

🎯 Attack Surface

✅ URL parameters with object IDs
✅ API endpoints with sequential IDs
✅ Form hidden fields
✅ Cookie values
✅ RESTful API paths
✅ File paths in requests

⚠️ Preconditions

Application uses predictable object references (IDs)
No proper authorization check on object access
User can guess/enumerate other object IDs

🔍 Detection

Manual Testing:

Change ID parameter in URL: /profile?id=1 → /profile?id=2
Test with different user sessions
Check for direct object references in API

🔧 Burp Suite Workflow

Login as regular user
Access own resource, capture request
Change object ID parameter
Check if unauthorized data returned
Test across different user accounts

⚙️ Tool Automation

🔫 Autorize

Automatic authorization tester

🛡️ Burp Suite

Manual with Intruder

⚡ nuclei

IDOR templates

💣 Basic Payloads

/api/users/1 → /api/users/2

/profile?id=123 → /profile?id=124

/order/1001 → /order/1002

/documents/secret.pdf → /documents/other.pdf

🚀 Advanced Payloads

🔄 Parameter Pollution

?user_id=1&user_id=2

?id=1&id=2

🔧 ID Enumeration

Numeric ID range: 1-10000

UUID enumeration

📝 Proof of Concept

# Normal user accessing own profile
GET /api/profile/USER123 HTTP/1.1
Authorization: Bearer user_token

# Attacker changes ID to another user
GET /api/profile/USER456 HTTP/1.1
Authorization: Bearer user_token

# Response returns USER456 data - VULNERABLE!

💥 Impact Analysis

Severity: HIGH (CVSS 7.5)

Data breach of all users' data
Privacy violation
Account takeover
Regulatory compliance violations

🔗 Attack Chains

Chain: IDOR to Full Account Takeover

Enumerate user IDs
Access admin API endpoints
Create admin user via IDOR
Full system access

🛡️ Mitigation

✅ Implement Authorization Checks: Verify user owns the object

✅ Use Indirect References: Map internal IDs to random tokens

✅ Add Access Control: Verify permissions before object access

🏰 Advanced Mitigation

Implement ABAC (Attribute-Based Access Control)
Add audit logging for all object access
Use UUIDs instead of sequential IDs
Implement rate limiting

📊 Monitoring & Detection

Alert on unusual access patterns
Monitor for mass object enumeration
Log all access control failures

🔐 Security Controls

Control	Implementation
Authorization	Check ownership on every request
Indirect References	Use random tokens instead of IDs
Logging	Log all object access

🛠️ Tools & Commands

Autorize

Burp extension for authorization testing

IDOREnumerator

Automated IDOR testing

📚 References

🔄 Retest Steps

Step	Action
1	Implement authorization checks
2	Re-test with different user IDs
3	Verify ownership validation

⚙️ Detection Logic

Static: Check for authorization on object access. Dynamic: Fuzz object IDs with different sessions.

🔎 Threat-Hunting Notes

IOCs: Multiple requests with sequential IDs, unusual access patterns, cross-user data access.

🛡️ Defensive Detection Ideas

Deploy RASP to monitor object access, implement automatic authorization testing in CI/CD.

🔴 Insecure Direct Object Reference (IDOR)