Broken Function-level Authorization (BFLA)
A Guide to Broken Function-level Authorization (BFLA)
Satisfying an API request consumes resources: network bandwidth, CPU, memory, storage, and sometimes paid third-party services like SMS or biometric validation. Unrestricted resource consumption occurs when an API fails to limit how much of that resource a single client interaction demands.
The risks posed by unrestricted resource consumption go well beyond a traditional denial-of-service concern. When an API integrates paid third-party services, a lack of spending limits turns resource consumption into a direct financial attack. A single automated script hitting an SMS-triggering endpoint generates thousands of dollars in charges within minutes.
GraphQL introduces a specific version of this risk: Its batching capability lets a client bundle hundreds of resource-intensive operations into one request, which sidesteps API rate limiting applied per individual request.
Key Takeaways
- Broken Function Level Authorization (BFLA) is ranked #5 in the OWASP API Security Top 10 2023 and occurs when APIs fail to enforce access controls on who can call specific functions or endpoints, not just which objects they can access
- Unlike BOLA (object-level), BFLA is about accessing entire API functions or endpoints that should be restricted, such as administrative endpoints accessible by regular or anonymous users
- Administrative endpoints are frequently found alongside regular endpoints rather than under a clearly separate path, making them discoverable through guessing or API structure analysis
- Attackers can exploit BFLA by changing HTTP methods (e.g., GET to DELETE), guessing endpoint URLs, or manipulating request parameters to trigger privileged functionality
- Prevention requires a deny-by-default authorization module applied consistently across all endpoints, with explicit role-based grants and authorization checks inherited by all administrative controllers
Why is it Dangerous
BFLA opens the door for adversaries targeting administrative functionality. Successful exploitation results in:
- Data disclosure through privileged read operations exposed to unauthorized users
- Data loss or corruption through privileged write and delete operations
- Service disruption when destructive administrative functions are triggered
- Privilege escalation without the need for credential theft
Typical Manifestations
BFLA commonly appears when:
- Administrative endpoints share a URL structure with regular user endpoints instead of a clearly separated path
- Changing the HTTP method on a request, such as switching GET to DELETE, triggers privileged functionality
- Guessing likely endpoint names or IDs exposes functions with no authorization check
- Authorization logic is implemented per endpoint rather than centrally, leaving gaps wherever a developer forgot the check
Each of these comes down to the same gap: The API verifies identity but never verifies whether that identity is allowed to invoke this specific function.
Preventing BFLA
An API should default to denying access and granting it only explicitly.
- Apply a deny-by-default authorization module across every endpoint, administrative or otherwise
- Grant access through explicit, role-based rules rather than assuming a function is safe because it isn’t linked from the UI
- Review every endpoint against function-level authorization flaws with the application’s user hierarchy and groups in mind
- Make sure every administrative controller inherits from an abstract controller that enforces role-based authorization checks
- Implement the same role-based checks for administrative functions living inside a regular, non-administrative controller
Hiding an administrative function is not the same as protecting it. If the endpoint exists, an attacker will eventually find it.
