graph LR

A[Attacker] --> B[Discover Endpoint]

B --> C[Identify Parameter]

C --> D[Modify Request]

D --> E{Access Control Check?}

E -->|Missing| F[Unauthorized Access]

E -->|Present but Weak| G[Bypass Logic]

G --> F

E -->|Properly Implemented| H[Access Denied]

Common Attack Patterns

1. Insecure Direct Object References (IDOR)

1. User logs in and accesses their profile

URL: /user/profile?id=12345

1. User observes the pattern (sequential IDs)

1. User modifies the ID parameter

URL: /user/profile?id=12346

1. If no authorization check exists:

→ User sees another person's profile

• User profiles and account data
• Order histories and invoices
• Document downloads
• API endpoints
• Database record access

• Predictable resource identifiers (sequential numbers, GUIDs)
• Missing ownership validation on the server
• Assumption that "hidden" URLs won't be discovered

2. Path Traversal for Access Control

1. Application serves user files from:

/files/user123/document.pdf

1. Attacker modifies the path:

/files/user456/document.pdf

OR

/files/../admin/secret.pdf

1. If path validation is missing:

→ Access to unauthorized files

• File download features
• Document management systems
• Profile picture/avatar systems
• Static resource serving

3. Privilege Escalation

Horizontal Escalation:

User A (customer) → Access User B's data (another customer)

Vertical Escalation:

Regular User → Access Admin functions

User → Root/System level access

• Role-based features (admin panels)
• API endpoints with different permission levels
• Bulk operations (export all data)
• System configuration pages

4. Forced Browsing

1. Attacker explores the application structure

1. Discovers patterns in URLs:

/user/dashboard

/user/settings

1. Guesses admin URLs:

/admin/dashboard (not linked but exists)

/admin/users

/api/admin/delete

1. If no role check exists:

→ Access to admin functionality

• Administrative interfaces
• Debug/test pages left in production
• API endpoints not documented publicly
• Legacy or deprecated features

5. Parameter Tampering

1. Legitimate request:

POST /update-profile

{ "user_id": 12345, "role": "user" }

1. Attacker adds/modifies parameters:

POST /update-profile

{ "user_id": 12345, "role": "admin", "is_admin": true }

1. If server doesn't validate:

→ User gains admin privileges

• Form submissions
• API requests
• Cookie manipulation
• Hidden form fields

6. Session/Token Manipulation

1. Observe session token pattern:

session_id=user_12345_2024

1. Predict another user's token:

session_id=user_12346_2024

1. If tokens are predictable:

→ Access another user's session

• Session cookies
• JWT tokens with weak secrets
• API keys
• OAuth implementations

7. Missing Function Level Access Control

1. Application has admin functions:

/api/users/delete

/api/settings/modify

1. Frontend hides buttons from non-admins

1. But backend doesn't check roles

1. Anyone who knows the endpoint:

→ Can execute admin functions

• RESTful APIs
• GraphQL queries/mutations
• Admin functions
• Bulk operations

Application Flaws That Enable Attacks

1. Client-Side Only Enforcement

{% if not user.is_admin %}

{% endif %}

2. Inconsistent Authorization Checks

Protected endpoint

@app.route('/api/users')

@require_admin

def list_users():

return jsonify(users)

OOPS! Forgot to protect this one

@app.route('/api/users/')

def get_user(id):

return jsonify(user) # Anyone can access!

3. Trusting User Input

VULNERABLE: Trusts user_id from request

@app.route('/profile')

def profile():

user_id = request.args.get('user_id') # From URL parameter

user = get_user_by_id(user_id)

return render_template('profile.html', user=user)

Should verify: Does current logged-in user own this user_id?

4. Broken Ownership Validation

VULNERABLE: Doesn't check if user owns the order

@app.route('/order/')

def view_order(order_id):

order = Order.query.get(order_id)

return render_template('order.html', order=order)

Should verify: current_user.id == order.user_id

5. CORS Misconfiguration

VULNERABLE: Allows all origins

@app.after_request

def add_cors_headers(response):

response.headers['Access-Control-Allow-Origin'] = '*'

response.headers['Access-Control-Allow-Credentials'] = 'true'

return response

Signs and Symptoms of Vulnerability

For Security Testers

Look for these indicators:

✅ Sequential IDs in URLs:

/document?id=1234 → Try id=1233, id=1235

/user/12345 → Try /user/12344, /user/12346

✅ Predictable Resource Paths:

/files/john_doe/report.pdf → Try /files/jane_smith/report.pdf

✅ Hidden Admin Links (in HTML source):

✅ API Endpoints Without Authentication Headers:

Request to /api/users succeeds without Authorization header

✅ Different Responses for Different Users:

User A requests /profile/123 → 200 OK

User B requests /profile/123 → Should be 403 Forbidden, but returns 200 OK

✅ Error Messages Revealing Information:

"User 12345 not authorized to access order 67890"

(Confirms order 67890 exists, information disclosure)

For Developers (Code Smells)

⚠️ No Authorization Checks:

@app.route('/sensitive-data')

def sensitive():

return data # Where's the permission check?

⚠️ Authorization in Frontend Only:

// Client decides whether to call API

if (userRole === 'admin') {

callAdminAPI();

}

⚠️ Hard-coded Role Checks:

if user.email == 'admin@example.com': # BAD: Hard-coded

grant_access()

⚠️ Missing Database Ownership Joins:

Gets resource without checking ownership

resource = Resource.query.get(resource_id)

⚠️ Trust of User-Supplied Roles:

role = request.form.get('role') # User can modify this!

if role == 'admin':

grant_admin_access()

What Attackers Look For

Reconnaissance Techniques

Attackers gather information to find access control weaknesses:

1. URL Pattern Analysis:
• Study URL structures
• Identify parameter names
• Detect ID formats (sequential, UUID, etc.)

1. JavaScript/Source Code Review:
• Inspect client-side code for API endpoints
• Find hidden features or admin links
• Discover business logic in frontend

1. HTTP Traffic Analysis:
• Intercept requests/responses
• Identify access control headers (or lack thereof)
• Map API endpoints

1. Role-Based Exploration:
• Create multiple accounts with different roles
• Compare functionality and endpoints
• Identify privilege differences

1. Error Message Analysis:
• Trigger errors to reveal system information
• Identify whether resources exist
• Discover technology stack

Common Discovery Methods

Test different values systematically:

/api/user?id=1

/api/user?id=2

/api/user?id=admin

/api/user?id=../admin

1. Log in as User A, perform action
2. Log in as User B, try same action
3. Check if User B can access User A's resources

Search for:

• Swagger/OpenAPI documentation
• GraphQL introspection
• JavaScript bundle analysis
• robots.txt
• sitemap.xml

Tools look for:

• Unprotected endpoints
• IDOR vulnerabilities
• Missing authentication
• Weak session management

Detection Techniques

Manual Testing

1. Create Account A and Account B
2. Log in as Account A, access A's resource
3. Note the resource ID (e.g., /profile?id=123)
4. Stay logged in as Account A
5. Try to access Account B's resource (e.g., /profile?id=124)
6. Expected: 403 Forbidden
7. Vulnerable if: 200 OK (access granted)

1. Log in as regular user
2. Try accessing admin URLs:

/admin

/admin/users

/api/admin/settings

1. Expected: 403 Forbidden or 404 Not Found
2. Vulnerable if: 200 OK or admin interface loads

1. Map all application URLs
2. Try accessing them without authentication
3. Try accessing them with low-privilege accounts
4. Expected: Proper access control enforcement
5. Vulnerable if: Sensitive pages accessible

Automated Testing

• Intercept traffic
• Test authorization on every endpoint
• Compare responses between different user roles

Conceptual test script

def test_idor(base_url, user_a_session, user_b_id):

"""Test if User A can access User B's profile"""

response = requests.get(

f"{base_url}/profile/{user_b_id}",

cookies=user_a_session

)

assert response.status_code == 403, "IDOR vulnerability detected!"