Broken Function Level Authorization

Broken Function Level Authorization (BFLA) occurs when an API fails to enforce proper access controls on administrative or privileged function endpoints, allowing regular users to invoke operations intended exclusively for higher-privilege roles. While BOLA concerns access to specific data objects, BFLA concerns access to entire functional capabilities—the difference between "can User A read User B's data?" (BOLA) and "can a regular user execute administrative functions?" (BFLA).

This vulnerability is particularly dangerous in APIs because the separation between regular and administrative functions is often implemented through separate client applications (user portal vs. admin dashboard) rather than server-side authorization checks. Developers may assume that because the admin functionality is not exposed in the regular user interface, it is inaccessible. However, since APIs are directly callable, any authenticated user who discovers or guesses admin endpoint URLs can invoke privileged operations.

BFLA commonly manifests in APIs that use predictable URL patterns for administrative functions (e.g., /api/v1/admin/users, /api/v1/users/delete), share the same API server for both user and admin functionality without role-based middleware, or rely on client-side role checks without corresponding server-side enforcement. The vulnerability is amplified in microservice architectures where authorization logic may be inconsistently applied across services.

Attackers discover privileged endpoints through several techniques. API documentation (Swagger/OpenAPI specs) often documents all endpoints including admin routes. Predictable naming conventions make admin endpoints guessable—if the user API follows /api/v1/users/{id}, attackers will try /api/v1/admin/users, /api/v1/users/{id}/delete, or /api/v1/users/{id}/role. Client-side JavaScript in single-page applications often contains references to admin API endpoints even when the UI conditionally hides admin features. Mobile app binaries can be decompiled to extract API endpoint URLs.

Once admin endpoints are discovered, the attacker issues requests using their regular user credentials. Common exploitation patterns include: changing user roles by calling PUT /api/v1/users/{id}/role with {"role": "admin"}, accessing user management functions to enumerate or modify all user accounts, invoking system configuration endpoints to change application settings, accessing reporting or export functions that return aggregate data across all users, and triggering destructive operations like data deletion or system resets.

In microservice architectures, BFLA exploitation may involve calling internal service endpoints that are exposed through the API gateway without authorization checks. Service-to-service communication that trusts all incoming requests (assuming they come from other trusted services) is vulnerable when the API gateway routes external user requests to these internal services without stripping or validating privilege claims.

• Vertical privilege escalation allowing regular users to perform administrative operations including user management, system configuration, and data export
• Complete system compromise when attackers promote their own accounts to administrator level and gain unrestricted access
• Mass data manipulation or deletion through access to administrative bulk operations not intended for regular users
• Unauthorized access to business intelligence, analytics, and reporting functions that aggregate sensitive cross-user data
• System configuration tampering that could disable security controls, modify authentication settings, or create backdoor accounts
• Compliance violations when audit trails show regular users performing administrative actions, indicating access control failures

1. Implement role-based access control (RBAC) or attribute-based access control (ABAC) as centralized middleware that executes before every API endpoint handler. Define explicit permission matrices mapping roles to allowed operations and enforce them consistently across all services.
2. Deny by default: every endpoint should require explicit authorization configuration. If a new endpoint is added without authorization rules, it should be inaccessible rather than open. Use framework features like route-level middleware or decorator-based authorization annotations.
3. Separate administrative API endpoints into distinct API servers or services with different authentication requirements (e.g., admin APIs require VPN access, additional MFA, or client certificate authentication). Use network-level controls to restrict access to admin API servers.
4. Implement authorization testing in CI/CD pipelines that verifies every endpoint rejects requests from insufficient privilege levels. Generate test cases from your RBAC permission matrix to ensure complete coverage of role-endpoint combinations.
5. Audit API documentation and OpenAPI specifications to ensure admin endpoints are not publicly documented. If using auto-generated documentation, configure it to exclude administrative routes from public-facing documentation.
6. Implement robust authorization logging that records the authenticated user's role, the requested operation, and the authorization decision (permit/deny) for every API call. Alert on authorization denials that indicate privilege escalation attempts.
7. In microservice architectures, propagate and validate authorization context (user identity and roles) through the entire service chain. Do not rely on network-level trust between services—every service should independently verify that the requesting user is authorized for the operation.

Begin by mapping the complete API surface area including administrative endpoints. Review API documentation, client-side JavaScript bundles, and mobile application binaries for references to privileged endpoints. Use tools like Kiterunner, which uses common API wordlists, to brute-force discover undocumented endpoints. Analyze the API URL structure to identify naming conventions and predict admin endpoint locations.

Perform systematic vertical privilege escalation testing by creating user accounts at different privilege levels (unauthenticated, regular user, moderator, admin). For each admin endpoint discovered, attempt access using each lower-privilege credential. Use Burp Suite's Autorize extension to automate this process: configure it with a regular user session and replay all admin requests through the low-privilege session, flagging any that succeed. Test both direct endpoint access and indirect privilege escalation through parameter manipulation (e.g., adding "role": "admin" to profile update requests).

Examine HTTP methods on all endpoints—some APIs restrict GET access but allow PUT or DELETE. Test whether changing the HTTP method from GET to POST, PUT, PATCH, or DELETE on user-level endpoints reveals administrative functionality. In microservice architectures, test whether internal service endpoints are accessible through the public API gateway. Verify that API versioning does not create authorization bypasses by testing older API versions that may have been deployed before authorization checks were added.