Broken Function Level Authorization (BFLA)

Broken Function Level Authorization is an API security vulnerability in which an application fails to properly restrict access to functions or actions based on a user’s role or privilege level. As a result, a lower-privileged user – or even an unauthenticated one – can invoke functionality that should be reserved for higher-privileged users, such as administrators. It is one of the named risks in the OWASP API Security Top 10.

The core failure is at the level of actions rather than data objects. Where Broken Object Level Authorization concerns accessing another user’s specific record, BFLA concerns performing an operation the user should not be allowed to perform at all. A classic example is a regular user changing an HTTP method or URL to reach an administrative endpoint – for instance, altering a GET /users request into DELETE /users/{id}, or discovering and calling an admin-only function like /admin/promoteUser that the API fails to gate by role. If the server does not verify that the caller holds the required privilege for that function, the action succeeds.

APIs are especially prone to BFLA because they often expose many functions across many endpoints, sometimes with predictable naming, and because authorization checks must be enforced consistently on every function-level call. Administrative and privileged endpoints are frequent targets. Attackers probe for these by manipulating request methods, paths, and parameters, looking for privileged operations that lack proper role enforcement.

The consequences can be severe: unauthorized creation, modification, or deletion of data; privilege escalation; and takeover of administrative capabilities. Preventing BFLA requires enforcing authorization checks on the server for every function based on the authenticated user’s role and permissions, denying access by default, cleanly separating administrative from regular functionality, and ensuring that no privileged action can be reached simply by knowing or guessing its endpoint. Because these flaws are logic-based and depend on each application’s roles, they often evade automated scanners and demand deliberate access-control testing.