IDOR & Bypass Techniques: A Practical Methodology for Security Testing

✓ Access other users' private data
✓ Modify unauthorized resources
✓ Delete critical information
✓ Often high severity = high bounty payouts

✓ IDOR identification techniques
✓ Systematic testing approach
✓ Bypass strategies
✓ Documentation framework
✓ Preventive measures

# Parameter-Based IDOR
/user/profile?id=12345
/order/view?order_id=789
/api/v1/users/12345
# Path-Based IDOR
/user/12345/profile
/orders/789/details
/download/file/12345.pdf
# Header-Based IDOR
X-User-ID: 12345
X-Account-Number: 789
# JSON/XML Body IDOR
{"user_id": 12345, "action": "view"}

High-Risk Features:
✓ Profile/account settings
✓ Order history and invoices
✓ Document downloads
✓ Financial transactions
✓ Messages and conversations
✓ Settings and configurations
✓ Admin panels
✓ APIs and microservices
Critical Patterns:
- Sequential numbers (1,2,3…)
- Predictable UUID patterns
- Encoded IDs (base64, hex)
- User-controlled parameters

# Common IDOR Parameters to Test
User Identifiers:
user_id, uid, userId, accountId, customerId
username, user_name, email, phone
Resource Identifiers:
id, order_id, invoice_id, document_id
file_id, message_id, comment_id, post_id
File Operations:
file, document, attachment, download
export, import, upload, view
Configuration:
setting_id, preference_id, config_id

# Mapping Access Control
1. Create a baseline:
 - Create own resources (profile, order, document)
 - Note the IDs assigned
 - Observe URL structure
2. Test resource access:
 - Access own resources → Success
 - Access random IDs → Observe response
 - Access existing IDs from other users → Test
3. Document findings:
 - Which endpoints are vulnerable?
 - What data is exposed?
 - What operations are possible?

# Systematic IDOR Testing
Test 1: Access Own Resource
GET /profile/123
Response: 200 - Your profile data
Status: Baseline - Working normally
Test 2: Adjacent ID
GET /profile/124
Response: 403/404 - Access denied
Status: Likely secure for this endpoint
Test 3: Nearby IDs
GET /profile/122
GET /profile/125
GET /profile/12345
Response: Monitor variations
Status: Look for inconsistent behavior
Test 4: Large Range
GET /profile/1
GET /profile/2
GET /profile/99999
Response: Check error messages
Status: Information disclosure possible

# Horizontal IDOR - Same Role, Different User
Vulnerable:
GET /user/profile?id=12345
- User A views User B's data
Safe:
GET /user/profile
- Only own data accessible
- ID inferred from session
# Vertical IDOR - Different Role, Same User
Vulnerable:
GET /admin/users/12345
- Regular user views admin data
Safe:
- Role-based access control
- Admin endpoint requires admin privilege

┌─────────────────┬──────────┬──────────┬──────────┐
│ User Type       │ Own Data │ Other ID │ Admin ID │
├─────────────────┼──────────┼──────────┼──────────┤
│ Regular User    │ 200 OK   │ ? Test   │ ? Test   │
├─────────────────┼──────────┼──────────┼──────────┤
│ Premium User    │ 200 OK   │ ? Test   │ ? Test   │
├─────────────────┼──────────┼──────────┼──────────┤
│ Admin User      │ 200 OK   │ 200 OK   │ 200 OK   │
└─────────────────┴──────────┴──────────┴──────────┘
Document each cell:
- Expected behavior
- Actual behavior
- Security implication

# Technique 1: Method Override
GET → POST /profile/12345
POST → PUT /profile/12345
DELETE → GET /profile/12345
# Technique 2: Parameter Pollution
GET /profile?id=12345&id=67890
GET /profile?user_id=12345&id=12345
# Technique 3: Encoding Variations
GET /profile/12345
GET /profile/12345%2f
GET /profile/12345%00
GET /profile/12345. (trailing dot)

# Test X-Headers
X-User-ID: 12345
X-Forwarded-User: 12345
X-Original-User: 12345
X-Authenticated-User: 12345
X-Impersonate: 12345
# Test Referer
Referer: https://admin.target.com/
Referer: https://target.com/admin/
# Test Cookies
user_id=12345
userId=12345
uid=12345

# Different locations for same parameter
GET /profile/12345
GET /profile?id=12345
GET /profile?user=12345
POST /profile {"id":12345}
PUT /profile {"userId":12345}

# Scenario: Filename instead of ID
Vulnerable:
/download/file/12345.pdf
Bypass:
GET /download/file/User_Invoice.pdf
- Try to predict filenames
- Check for pattern in naming
# Scenario: Multi-step Bypass
1. Access /order/view/12345
2. If blocked, try /order/12345/view
3. If blocked, try /order/view?id=12345
4. Document all variations that work

# Test batch operations vulnerable to IDOR
POST /api/v1/users/update_batch
{
 "users": [12345, 67890, 99999],
 "status": "deactivated"
}
POST /api/v1/orders/bulk_download
{
 "order_ids": [12345, 67890]
}
# Look for:
- Any user can update other users
- Non-admin can modify restricted fields
- Batch operations bypass checks

# Test IDOR in GraphQL
query {
 user(id: 12345) {
 email
 orders { id total }
 }
}
# GraphQL specific vectors:
- Combine with field-level access
- Test nested queries
- Bypass with aliases

# Test different API versions
/api/v1/users/12345
/api/v2/users/12345
/api/v3/users/12345
# Each version may have different access controls
# Older versions often more permissive

# IDOR Vulnerability Finding
**Title:** [Insecure Direct Object Reference]
**Affected Endpoint:** [URL]
**Risk Level:** [Critical/High/Medium/Low]
**Description:**
The application exposes [resource type] via direct object reference
without proper authorization checks.
**Vulnerable Parameter:** `[parameter_name]`
**Affected Users:** [All authenticated users]
**Steps to Reproduce:**
1. Login as [user type]
2. Access own resource at [endpoint]
3. Note the ID/Reference
4. Modify to [different user's resource]
5. Observe unauthorized access
**Impact:**
[What data can be accessed]
[What actions can be taken]
**Proof of Concept:**
[Request/Response examples]
**Remediation:**
1. Implement proper authorization checks
2. Use session-based user identification
3. Never trust user-supplied IDs
4. Implement indirect reference maps

# IDOR Risk Rating Guide
CRITICAL (9.0–10.0):
- Admin panel access
- Full user data exposure
- Financial transaction modification
- Password/credential viewing
HIGH (7.0–8.9):
- Sensitive personal data
- Order history with payment info
- Document downloads
- Account modification
MEDIUM (4.0–6.9):
- User profile (non-sensitive)
- Preferences and settings
- Non-financial history
LOW (0.1–3.9):
- Public data
- Already available elsewhere
- Informational only

# Authorization Best Practices
1. NEVER trust client-side input:
 - All ID parameters are suspect
 - Validate against session data
 - Implement server-side checks
2. Use indirect references:
 - Map real IDs to random tokens
 - Use UUIDs instead of integers
 - Implement hash-based references
3. Implement proper authorization:
 - Check user role/permission
 - Verify resource ownership
 - Validate action authorization
4. Centralize access control:
 - Use middleware/filters
 - Create reusable authorization logic
 - Single source of truth for rules
5. Log and monitor:
 - Track access attempts
 - Alert on suspicious patterns
 - Audit trail for sensitive operations

# IDOR Testing Checklist
□ Identify all ID parameters
□ Test incremental values
□ Test boundary values
□ Test missing/empty values
□ Test negative numbers
□ Test special characters
□ Test encoded values
□ Test different HTTP methods
□ Test different API versions
□ Test batch operations
□ Test both authenticated/unauthenticated
□ Test privilege escalation
□ Document all findings
□ Verify fixes

┌─────────────────────────────────────────────┐
│ PHASE 1: UNDERSTAND IDOR                    │
│ • Identify patterns                         │
│ • Map vulnerable features                   │
│ • Recognize common formats                  │
└─────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────┐
│ PHASE 2: RECONNAISSANCE                     │
│ • Parameter inventory                       │
│ • Identify access patterns                  │
│ • Document endpoints                        │
└─────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────┐
│ PHASE 3: TEST METHODOLOGY                   │
│ • Incremental testing                       │
│ • Horizontal/vertical IDOR                  │
│ • Systematic enumeration                    │
└─────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────┐
│ PHASE 4: BYPASS TECHNIQUES                  │
│ • Request manipulation                      │
│ • Header modification                       │
│ • Parameter position change                 │
│ • Multi-step bypass                         │
└─────────────────────────────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────────┐
│ PHASE 5: ADVANCED TESTS                     │
│ • Batch operations                          │
│ • GraphQL vectors                           │
│ • API version testing                       │
└─────────────────────────────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────────┐
│ PHASE 6: DOCUMENTATION                      │
│ • Clear findings                            │
│ • Risk assessment                           │
│ • Remediation guidance                      │
└─────────────────────────────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────────┐
│ PHASE 7: PREVENTION                         │
│ • Secure implementation                     │
│ • Testing checklist                         │
│ • Verification process                      │
└─────────────────────────────────────────────┘

1. IDOR is about authorization, not authentication
2. Systematic testing finds more than random attempts
3. Every endpoint with IDs should be tested
4. Horizontal IDOR is most common, vertical is most dangerous
5. Document with clear proof and impact
6. Verify fixes thoroughly

1. Never trust user-supplied IDs
2. Implement authorization at every access
3. Use indirect references where possible
4. Test your own implementations regularly
5. Monitor for suspicious access patterns
6. Centralize authorization logic