🔐 OWASP API Security

API5: Broken Function Level Authorization

📋 Overview

Broken Function Level Authorization is a critical vulnerability that occurs when APIs fail to properly enforce authorization checks for different user privilege levels. This vulnerability allows attackers to access functionality or data that should be restricted to users with higher privileges.

🎯 What is Broken Function Level Authorization?

This vulnerability focuses on the fact that some users might be able to edit properties of their own accounts in unauthorized ways. For example, a regular user might be able to change a property like user.admin to true, suddenly granting themselves administrator access to the entire application.

⚠️ Critical Impact: If a user can make themselves an administrator, they can control the entire application and potentially pivot to other internal applications. This represents a severe security breach.

💡 Understanding Shadow Properties

Shadow properties are object properties that developers include but may not be immediately visible or documented. These are hidden parameters that can be discovered and potentially exploited.

Shadow Property Example:

Request (Visible): { "username": "john", "email": "[email protected]" }

Response (Hidden Property): { "username": "john", "email": "[email protected]", "isAdmin": false }

An attacker might copy the isAdmin property from the response and include it in their next request, attempting to set it to true.

🔍 Why This Vulnerability Exists

Humans are predictable and tend to follow patterns in API design. This makes it easier for attackers to guess endpoints and parameters:

Predictable Endpoint Patterns: Higher privilege endpoints are often hosted on similar relative paths
Structured API Design: APIs follow structured approaches, making patterns easier to identify
HTTP Method Predictability: If a POST method exists, DELETE or PUT methods might also exist

Endpoint Pattern Example

/user/test

➜

/admin/test

POST /api/users

➜

DELETE /api/users

➜

PUT /api/users

📊 Real-World Example 1: Franchise System

Scenario: Restaurant Franchise Management

Consider a franchise system like McDonald's or Wendy's with two account types:

Account Type	Description	Privileges
Franchisee	Individual restaurant operator	Manage own location
Franchise Holder	Corporate franchise owner	Manage all locations, system-wide access

Exploitation:

Original Request: { "accountType": "franchisee" }

Modified Request: { "accountType": "franchiseHolder" }

Alternative Attempts: { "accountType": "franchise_holder" } or { "accountType": "admin" }

An attacker might guess variations like "franchiseHolder", "franchise_holder", or "admin" to elevate their privileges.

📊 Real-World Example 2: Document Export System

Scenario: Document Management API

Users can only see and export their own documents. However, an attacker might discover hidden endpoints:

Normal User Access:

GET /api/documents/export

Returns: Document1.pdf, Document4.pdf (user's own documents only)

Potential Exploitation:

GET /api/documents/export/all

⚠️ Potentially returns: ALL documents from ALL users

Attack Flow Visualization

User Documents
(Doc1, Doc4)

➜

Guess Endpoint
/export/all

➜

All Documents
(Doc1-Doc100)

🛡️ Three Main Exploitation Methods

1. URL Manipulation

Modifying the endpoint path to access restricted resources:

Original: GET /api/documents/export

Modified: GET /api/documents/export/all

2. Parameter Manipulation

Changing request parameters to elevate privileges:

Original: { "userId": "123", "role": "user" }

Modified: { "userId": "123", "role": "admin", "isAdmin": true }

3. HTTP Method Manipulation

Changing the HTTP method to access different functionality:

Original: GET /api/documents/1

Modified: DELETE /api/documents/1

Modified: POST /api/documents { "userId": "victim_id", "content": "malicious" }

🔧 Testing Methodology

Required Testing Factors:

User Groups: Test with multiple user types (admin, regular user, guest)
Authorization Levels: Verify each privilege level is properly enforced

Testing Process:

Step 1: Identify all API endpoints and their intended access levels

Step 2: Create test accounts with different privilege levels

Step 3: Use Burp Suite to intercept and modify requests

Step 4: Test each parameter individually for privilege escalation

Step 5: Attempt HTTP method changes (GET → POST, POST → DELETE, etc.)

Step 6: Try adding "/all", "/admin", or similar suffixes to endpoints

Step 7: Check responses for hidden properties (shadow properties)

Step 8: Document all findings and verify with manual testing

🛡️ Prevention and Mitigation Strategies

1. Separate Authentication and Authorization

Keep authentication/authorization modules separate from the main application code:

Use microservices architecture with dedicated auth containers
Deploy authorization modules on separate servers
Implement centralized authorization logic

2. Regular Testing and Analysis

Conduct thorough testing of authorization modules on a regular basis

Analyze application logic to identify potential authorization gaps

Review all API endpoints and their required privilege levels

3. Parameter Validation

Index and validate every parameter:

Create an inventory of all sensitive parameters (isAdmin, role, accountType, etc.)

Implement server-side validation for all parameters

Never trust client-supplied authorization data

Use allowlists for valid parameter values

4. Test Automation

Implement automated testing for authorization checks:

Define test cases for each privilege level and endpoint combination

Create automated tests that run on every deployment

Maintain test coverage for all API endpoints

Set up continuous monitoring for authorization failures

5. Access Control Best Practices

Deny by Default: Require explicit permission for all actions
Role-Based Access Control (RBAC): Implement proper role hierarchy
Attribute-Based Access Control (ABAC): Consider context in authorization decisions
Least Privilege: Grant only the minimum necessary permissions

🔍 Manual Testing with Burp Suite

Step-by-Step Process:

1. Configure Burp Suite as your proxy and capture API requests

2. Send interesting requests to Burp Repeater for manipulation

3. Identify all parameters in the request (headers, body, URL parameters)

4. Test each parameter individually by modifying values

5. Look for shadow properties in API responses

6. Copy response properties to requests and test for privilege escalation

7. Try different HTTP methods on the same endpoint

8. Attempt to access admin endpoints by modifying URL paths

9. Use Burp Intruder for automated parameter fuzzing with wordlists

🤖 Automation vs Manual Testing

⚠️ Important Consideration

While automation is valuable for repetitive testing, manual testing remains essential for discovering authorization vulnerabilities.

Testing Approach	Strengths	Limitations
Automated Testing	• Fast and repeatable • Good for regression testing • Consistent coverage	• Cannot understand context • Limited pattern recognition • Cannot guess user roles
Manual Testing	• Understands business logic • Can identify shadow properties • Better at guessing patterns • Context-aware testing	• Time-consuming • May miss repetitive checks • Requires skilled testers

🎯 Recommended Approach: Hybrid Testing

Combine both approaches for optimal results:

Use automation for baseline checks and regression testing
Employ manual testing for complex authorization logic
Keep humans in the loop for context-aware security testing
Leverage automation to support manual testers, not replace them

🔑 Key Takeaways

            Shadow Properties: Always look for hidden parameters in API responses
Predictable Patterns: Humans design APIs with patterns - use this to your advantage
                
Test All Variations: Try different HTTP methods, URL patterns, and parameter values
                
Business Logic: Understand the application flow to identify potential
                    vulnerabilities
Multiple User Roles: Test with different privilege levels to ensure proper
                    authorization
Parameter-First Approach: Focus on discovering parameters, then think about
                    exploitation
Keep Humans Involved: Robots cannot replace human intuition in security testing
                
Regular Testing: Authorization vulnerabilities can be introduced during development
                

        

Complete Attack Chain Visualization

Reconnaissance
(API Discovery)

↓

Parameter Analysis
(Shadow Properties)

↓

Privilege Testing
(Role Manipulation)

↓

Endpoint Guessing
(Pattern Analysis)

↓

Exploitation
(Unauthorized Access)

⚠️ Final Reminder

This vulnerability is complex and requires thorough understanding of application logic. Don't rely solely on automated tools. Develop your intuition through practice and always consider the business context when testing for broken function level authorization.