Category: Identity and Access Management
Broken Function Level Authorization
Also known as: BFLA, Function Level Access Control Vulnerability, API5:2023
Simply put
Broken Function Level Authorization is a security vulnerability where an application or API fails to properly restrict which users can invoke certain functions or actions. This allows regular or unauthorized users to access privileged operations, such as administrative functions, that should be off-limits to them. The risk is particularly prominent in APIs, where endpoint discovery may be easier and access control checks are often inconsistently applied.
Formal definition
Broken Function Level Authorization occurs when an API or application fails to enforce adequate authorization checks at the function or endpoint level, allowing authenticated or unauthenticated users to invoke operations beyond their assigned privilege level. Unlike object-level authorization flaws, which concern access to specific data records, BFLA concerns access to privileged functional capabilities, such as administrative endpoints, elevated HTTP methods (e.g., DELETE, PUT), or restricted workflows. The vulnerability typically arises when authorization logic is absent, inconsistently applied, or relies solely on client-side controls or UI-level obscurity rather than server-side enforcement. Detection typically requires deep analysis of the authorization mechanism across all exposed endpoints, including those not surfaced in the standard user interface, and testing with differing user roles and privilege levels. Static analysis tooling may identify missing authorization decorators or middleware in some frameworks, but determining whether authorization logic is semantically correct generally requires runtime testing or dynamic analysis in context.
Why it matters
Broken Function Level Authorization represents one of the most impactful classes of access control failures in modern API-driven applications. When authorization checks are absent or inconsistently applied at the function level, an attacker who gains access as a low-privileged user may be able to invoke administrative endpoints, trigger destructive operations such as bulk deletions, or escalate their capabilities without any additional credential compromise. The consequences typically include unauthorized data modification, privilege escalation, and full administrative takeover of application functions.
Who it's relevant to
API Developers and Backend Engineers
Developers building APIs are responsible for ensuring that authorization checks are enforced server-side on every endpoint and every HTTP method, not just those surfaced in the UI. BFLA commonly emerges when teams add administrative or internal endpoints for convenience and rely on obscurity rather than explicit access control. Developers must apply consistent authorization middleware or decorators across all routes, including those intended for internal or tooling use.
Application Security Engineers and Penetration Testers
Security engineers need to test for BFLA by mapping all exposed API endpoints, including those not linked from the standard user interface, and attempting to invoke each with credentials from lower-privileged roles. Static analysis tooling may flag missing authorization decorators or middleware in certain frameworks, but determining whether authorization logic is semantically correct for a given role typically requires runtime testing or dynamic analysis. False negatives are common with automated scanners because correct enforcement depends on business logic context that tools cannot fully evaluate without execution.
Security Architects
Architects designing multi-role or multi-tenant systems must establish a consistent, centrally enforced authorization model that governs function-level access across the entire API surface. Relying on UI-level controls or per-team implementation of access checks creates inconsistency that frequently leads to BFLA vulnerabilities. A well-designed authorization layer should enforce role-based or attribute-based access decisions at a single enforcement point rather than distributing that responsibility across individual endpoint handlers.
Product and Platform Owners
Organizations exposing APIs to external developers, partners, or customers face elevated risk from BFLA because their API surface is intentionally accessible and may be explored systematically by consumers. Platform owners should ensure that API documentation accurately reflects intended access boundaries, that privileged endpoints are not inadvertently exposed in public API schemas, and that authorization controls are validated as part of the release process for any new or modified endpoints.
Inside BFLA
Function-Level Access Control
The enforcement mechanism that determines whether an authenticated or unauthenticated user is permitted to invoke a specific API endpoint or application function, evaluated independently for each request.
Administrative and Privileged Endpoints
Higher-privilege functions, typically intended for administrators or internal roles, that are commonly targeted in BFLA attacks when access controls are absent or inconsistently applied.
HTTP Method Abuse
The exploitation of insufficiently restricted HTTP methods (such as PUT, DELETE, or PATCH) on endpoints that may restrict GET access but fail to enforce controls on other verbs.
Horizontal and Vertical Privilege Escalation
Two escalation patterns relevant to BFLA: vertical escalation occurs when a lower-privileged user accesses functions reserved for higher roles, while horizontal escalation occurs when a user accesses functions belonging to a peer user account.
Authorization Logic Centralization
The architectural practice of consolidating access control decisions into a shared, reusable component rather than implementing checks ad hoc within individual functions, reducing the risk of inconsistent enforcement.
Endpoint Enumeration Risk
The threat that attackers can discover undocumented or internal endpoints through API schemas, JavaScript bundles, or observed traffic patterns, and then probe those endpoints for missing authorization checks.
Common questions
Answers to the questions practitioners most commonly ask about BFLA.
If my application uses HTTPS and requires login to access it, does that mean my function-level authorization is already secure?
No. Authentication (requiring login) and transport security (HTTPS) are separate controls from authorization. Broken Function Level Authorization occurs when authenticated users can access functions or endpoints they should not be permitted to use. An attacker who is legitimately logged in as a low-privileged user may still be able to invoke administrative or privileged functions if the application does not enforce authorization checks at the function level, regardless of whether HTTPS is in use.
Does hiding admin endpoints or removing them from the UI mean they are protected from unauthorized access?
No. Security through obscurity is not a substitute for access control enforcement. If an endpoint exists and the server processes requests to it, an attacker can discover it through techniques such as forced browsing, API specification review, JavaScript analysis, or directory enumeration. Authorization must be enforced server-side on every request to a sensitive function, independent of whether that function is exposed in the user interface.
How should I implement function-level authorization checks in a way that scales across a large application?
A recommended approach is to enforce authorization centrally through a shared middleware layer, policy enforcement point, or framework-level mechanism rather than adding individual checks in each function or controller. This reduces the risk of inconsistent or missing checks. Role-based or attribute-based access control policies should be defined explicitly, and every request to a sensitive function should pass through the enforcement layer before any business logic is executed.
How can I test my application for Broken Function Level Authorization vulnerabilities?
Testing typically involves mapping all available endpoints and functions, then attempting to access each one using accounts with different privilege levels, including unauthenticated requests. Testers should pay particular attention to HTTP methods (for example, attempting POST or DELETE where only GET is expected), administrative or internal endpoints, and any functionality that differs between user roles. Both manual testing and automated tools can assist, though automated tools may produce false negatives for authorization logic that depends on application-specific context.
Should authorization checks be enforced on the client side, the server side, or both?
Authorization must always be enforced on the server side. Client-side controls such as hiding UI elements, disabling buttons, or restricting navigation are useful for user experience but provide no security guarantee, because an attacker can bypass them by sending requests directly to the server. Server-side enforcement on every incoming request is the authoritative control. Client-side restrictions may be applied in addition, but never as a replacement.
What is the difference between Broken Function Level Authorization and Broken Object Level Authorization, and do I need to address both?
Broken Object Level Authorization (BOLA) refers to cases where a user can access or manipulate a specific data object they should not have access to, typically by manipulating an identifier in a request. Broken Function Level Authorization refers to cases where a user can invoke an operation or endpoint that should be restricted based on their role or privilege level. Both vulnerabilities are distinct and require separate controls. An application may be vulnerable to one, the other, or both, so authorization design should address object-level access and function-level access as independent concerns.
Common misconceptions
If an endpoint is not publicly documented or linked in the UI, it is effectively protected from unauthorized access.
Security through obscurity does not constitute access control. Attackers can discover unlisted endpoints through API specification files, JavaScript source analysis, network traffic inspection, and fuzzing. Authorization checks must be enforced server-side regardless of whether an endpoint is advertised.
Authentication is sufficient to prevent broken function level authorization issues.
Authentication confirms identity but does not enforce permissions. BFLA occurs after successful authentication when the application fails to verify whether the authenticated user is permitted to invoke a particular function. The two controls are distinct and both are required.
BFLA only affects administrative functions and poses limited risk for standard application features.
While administrative endpoints are a common target, BFLA vulnerabilities can exist in any function that should be restricted by role, account ownership, or subscription tier. Sensitive operations such as bulk data export, account modification, or billing changes may all be exploitable if function-level checks are missing.
Best practices
Implement a centralized, reusable authorization component that enforces function-level access control consistently across all endpoints, rather than relying on per-function ad hoc checks that are prone to omission.
Apply a default-deny policy for all endpoints, requiring explicit permission grants for each role rather than assuming functions are restricted unless otherwise flagged.
Enforce authorization checks for every HTTP method on a given endpoint independently, not only for the primary method, since access controls on GET do not automatically apply to PUT, DELETE, or PATCH on the same route.
Include function-level authorization testing in your API security test suite, covering attempts by lower-privileged authenticated users to invoke higher-privilege operations, and verifying that all privileged endpoints reject unauthorized requests with appropriate status codes.
Audit API schemas, route definitions, and deployment configurations regularly to identify endpoints that may have been added or modified without corresponding authorization policy updates.
Integrate authorization control reviews into the development workflow so that any new endpoint or function requires documented role permissions before deployment, reducing the likelihood of controls being deferred or forgotten.