Cybersecurity glossary
What is Broken Function-Level Authorization (BFLA)?
Learn what Broken Function-Level Authorization (BFLA) is, how attackers reach admin or privileged API functions, real-world examples, and how to enforce role checks on every sensitive operation.
Definition
Broken Function-Level Authorization (BFLA) is an API security weakness where the server fails to enforce whether the authenticated caller is allowed to invoke a specific function or endpoint—such as admin, moderation, or batch operations—allowing horizontal or vertical privilege escalation through otherwise valid requests.
Why BFLA matters
Modern products expose dozens of privileged operations as APIs: refunds, user bans, configuration changes, data exports. Broken Function-Level Authorization (BFLA) occurs when those functions trust authentication alone—or UI hiding—without verifying the caller’s right to invoke them.
One missed role check on an admin route is often enough for full vertical privilege escalation.
Where function checks fail
Admin routes without roles
Endpoints under /admin assume only admins will find them.
Verb confusion
GET is protected but POST/PUT/DELETE variants of the same resource are not.
Client-only enforcement
Mobile or SPA hides buttons while the API still accepts the call.
Inconsistent microservices
Gateway checks roles for some routes; newer services forget the same policy.
Typical BFLA attack path
Authenticate as a normal user
Obtain a low-privilege access token or session.
Discover privileged functions
Mine OpenAPI docs, front-end bundles, or guess admin paths.
Invoke sensitive operations
Call export, delete, role-change, or configuration endpoints.
Observe missing denials
HTTP 200 where 403 was expected confirms BFLA.
Escalate impact
Create admin users, exfiltrate data, or alter billing state.
Automate abuse
Script privileged functions for scale once access is proven.
BFLA vs related authorization bugs
| Issue | Failed question | Example |
|---|---|---|
| BFLA | May this role call this function? | User hits admin refund API |
| BOLA | May this user access this object? | User reads another account’s order |
| BOPLA | May this user read/write this property? | User sets isAdmin=true in PATCH |
Preventing BFLA
- Deny by default; explicitly authorize every privileged operation.
- Centralize role/permission checks in server-side policy components.
- Map each sensitive endpoint to required permissions in OpenAPI and code reviews.
- Test low-privilege identities against the full admin surface in CI and pentests.
- Do not equate authentication with authorization.
- Align gateway route policies with service-level function checks.
- Alert on repeated 403 probing of admin function namespaces.
- Review new endpoints for missing authz annotations before release.
The practical takeaway
BFLA is “the wrong person called a privileged function, and the API allowed it.” Hide nothing behind URLs alone—authorize every sensitive operation on the server.
Pair function checks with object- and property-level controls so privilege models are complete end to end.
Related security terms
Broken Object-Level Authorization (BOLA)
Object access failures; BFLA instead concerns which functions may be called.
Privilege Escalation
Broader outcome when function checks are missing.
Role-Based Access Control (RBAC)
Common model for granting function permissions by role.
API Endpoint
The callable unit that must declare and enforce authorization.
API Abuse
Hostile use of privileged functions once authorization is bypassed.
Frequently asked questions
What is BFLA in simple terms?
The API has an admin or special action, and a normal user can call it successfully because the server never checks their role for that action.
How is BFLA different from BOLA?
BOLA is about accessing the wrong object (another user’s record). BFLA is about calling the wrong function (an admin-only operation).
Where does BFLA appear in OWASP?
It is highlighted in the OWASP API Security Top 10 as Broken Function Level Authorization.
What are common BFLA examples?
User calling DELETE /admin/users/{id}, exporting all accounts, changing feature flags, or triggering billing adjustments without an admin role.
Does hiding admin URLs fix BFLA?
No. Security through obscurity fails. The server must authorize every privileged function regardless of UI visibility.
Can gateways alone stop BFLA?
Gateways can enforce coarse role claims on routes, but complex function policies still need consistent server-side checks.
How do you test for BFLA?
Authenticate as a low-privilege user and systematically attempt privileged operations discovered via docs, JS bundles, or fuzzing.
References
Explore authoritative guidance and frameworks related to broken function-level authorization (bfla).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.