Broken function level authorization is what lets a normal user reach an administrator function. This page explains what BFLA is, how it differs from BOLA, how attackers reach privileged functions, and how Planck Operator proves it by sending privileged-function requests from lower-privileged roles and confirming the action succeeds.
Broken function level authorization, listed as API5:2023 in the OWASP API Security Top 10 and mapped to CWE-285, occurs when an API does not enforce role and privilege checks at the function or endpoint level. The server confirms the caller is authenticated, but never confirms the caller role is permitted to perform this particular action.
The function executes because the request reached it, not because the caller was authorized to invoke it. Role enforcement is assumed to happen in the client, or is applied inconsistently across routes and methods.
The result is vertical escalation: a normal account performs operations reserved for administrators or privileged service roles, such as promoting users, changing configuration, or deleting other accounts.
Administrative routes omitted from the client interface are still reachable over HTTP. If the only thing hiding a function is the absence of a button, it is not access control.
The two authorization flaws at the top of the OWASP list are easy to conflate and important to separate. BOLA is authorization on the data object: can you reach a record that belongs to someone else. BFLA is authorization on the function: can you invoke an operation your role should never be able to perform.
BOLA usually moves horizontally, between peers at the same privilege level. BFLA usually moves vertically, escalating a standard user into administrative capability. An API can have one, the other, or both, which is why we test them as distinct classes. For a side-by-side treatment, see our writeup on BOLA versus BFLA authorization flaws and the companion BOLA testing page.
An attacker starts from a legitimate low-privileged account and probes for functions the role should not reach. The techniques are simple and effective when the server routes on path and method without re-checking the caller.
Call administrative endpoints directly with a normal user token. If the function runs, the role check was missing or trusted the client to hide the route.
Turn a permitted GET into a PUT, PATCH, or DELETE on the same path. Frameworks often protect the method the client uses and leave the others open.
Enumerate conventional administrative paths, versioned variants, and internal routes that never appear in the client but remain live on the server.
You provide one bearer token per role. Planck Operator enumerates every function the API exposes from its specification, then sends each privileged-function request from a lower-privileged role and confirms whether the action actually succeeds, rather than assuming a 403 that never comes.
It exercises alternate HTTP methods on every route, tests undocumented and administrative paths uncovered during discovery, and works from the spec so functions no current client calls are still checked. Because it reruns continuously, a role check dropped by a new deploy is caught quickly rather than at the next annual test.
A simplified illustration using safe placeholder values. A standard user calls an administrative function that promotes an account to admin.
POST https://api.example.com/v2/admin/users/3310/roles HTTP/1.1
Host: api.example.com
Authorization: Bearer <standard-user-token>
Content-Type: application/json
{ "role": "admin" }
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 3310, "role": "admin", "updated": true }
The token belongs to a standard user with no administrative rights, yet the privileged role-assignment function executed and returned success. The finding ships with the request, the successful response, and a baseline showing the same call denied for the role the API intends to gate, so the escalation is reproducible and verifiable on retest.
Deny by default and enforce an explicit role check on every function on the server. Authorization must be based on the authenticated identity and its role, applied consistently across all HTTP methods for a route, and it must never depend on the client hiding a control.
BFLA, broken function level authorization, is listed as API5:2023 in the OWASP API Security Top 10. It occurs when an API fails to enforce role and privilege checks at the function or endpoint level, so a lower-privileged user can invoke a function reserved for administrators or other privileged roles. It is authorization on the action, whereas BOLA is authorization on the data object.
BOLA is about objects: can you reach a data record that belongs to someone else. BFLA is about functions: can you invoke an operation your role is not permitted to perform. BOLA moves horizontally between peers, while BFLA typically moves vertically, escalating a standard user into administrative capability. An API can be vulnerable to one, the other, or both.
An attacker authenticates as a normal user and then calls privileged endpoints directly, guesses administrative routes that the client hides, or changes the HTTP method on a known path, for example turning a permitted GET into a DELETE or a PUT the interface never exposes. If the server routes on the URL and method without re-checking the caller role, the privileged action succeeds.
You provide one token per role. Operator enumerates every function the API exposes from the specification, then sends each privileged-function request from a lower-privileged role and confirms whether the action actually succeeds. It also tries alternate HTTP methods and undocumented administrative routes, so functions no client currently calls are still tested.
Deny by default and enforce an explicit role check on every function on the server, not in the client. Authorization should be based on the authenticated identity and its role, applied consistently across all HTTP methods for a route, and centralized so that new endpoints inherit enforcement rather than each reimplementing it.
Give us one token per role and the agent will send every privileged-function request from a lower-privileged role, then hand you reproducible evidence of anything that succeeds.