Broken Access Control

Broken Access Control is #1 on OWASP Top 10:2025, with 40 associated CWEs. It's the most common vulnerability class and a goldmine for bug bounty hunters.

Understanding Access Control

Access control enforces:

• Authentication: Who are you?
• Authorization: What can you do?
• Accountability: What did you do?

When these fail, users access resources they shouldn't.

IDOR (Insecure Direct Object Reference)

The most common access control bug:

# Normal request
GET /api/user/profile?id=1001

# Attacker changes ID
GET /api/user/profile?id=1002  # Access another user's data

Testing IDORs

# Step 1: Create two accounts (user A and user B)
# Step 2: Get user A's resource ID
# Step 3: As user B, try to access user A's resource

# Common IDOR patterns
/api/users/{user_id}
/api/orders/{order_id}
/api/documents/{doc_id}
/download?file_id={id}
/invoice/view/{invoice_number}

IDOR Hunting Tips

Pattern	Test
Sequential IDs	Try id-1, id+1
UUIDs	Still test—often predictable
Encoded IDs	Decode base64, try variations
Composite keys	Change user_id in user_id-resource_id

BOLA (Broken Object Level Authorization)

IDOR for APIs—OWASP API Security #1:

# Normal: Get your own data
GET /api/v1/users/me/orders

# Attack: Access another user's orders
GET /api/v1/users/12345/orders

Testing BOLA

# Using Burp Suite
1. Capture request with your user token
2. Change the object ID in URL/body
3. Send with your auth token
4. Check if you can access other users' data

# Automate with Autorize extension
# - Configure two sessions (low privilege, high privilege)
# - Extension replays requests between sessions

Privilege Escalation

Horizontal Escalation

Same privilege level, different user:

User A → User B's data

Vertical Escalation

Lower to higher privilege:

Regular user → Admin functionality

Common Vectors

# Hidden admin parameters
POST /api/update-profile
{"name": "Attacker", "role": "admin"}

# Forced browsing
/admin/dashboard  # Try even without link

# Parameter manipulation
/api/users?role=user → /api/users?role=admin

# Cookie/JWT manipulation
# Change role claim in JWT: "role": "user" → "role": "admin"

Testing Methodology

1. Map all endpoints with different privilege levels
2. Create test accounts for each role (admin, user, guest)
3. Cross-test requests between accounts
4. Check response codes AND body (403 but data leaks)
5. Test state changes: Can user B modify user A's data?

Automation

# Using Nuclei
nuclei -l endpoints.txt -tags idor,bac -o access-control-findings.txt

# Custom Burp extension setup
# Autorize: Automatic access control testing
# AuthMatrix: Role-based access matrix testing

Real-World Examples

Company	Bug	Bounty
Facebook	IDOR in business pages	$15,000
Uber	Access other riders' trips	$8,000
HackerOne	Read private reports	$10,000
Shopify	Modify other stores' products	$15,000

Report Template

## Broken Access Control: IDOR in Order API

### Summary
Users can access other users' order details by manipulating the order_id parameter.

### Steps to Reproduce
1. Login as User A, note order ID: 12345
2. Login as User B, capture any authenticated request
3. Send: GET /api/orders/12345 with User B's session
4. Observe: User A's order details returned

### Impact
- Access to PII (name, address, phone)
- Financial information exposure
- GDPR/privacy violation

### Severity: High

Pro Tip: Always test access control with at least two accounts. The bug isn't in changing IDs—it's in the server accepting unauthorized requests.

Next, we'll explore injection attacks: SQL injection, XSS, and command injection. :::