Broken function-level authorisation

What it means

Broken function-level authorisation means an API lets a caller reach a function they should not, such as an admin action used by an ordinary account. It is a missing check on what you may do, where the related BOLA problem is a missing check on which record you may touch. The test is simple to describe: does the server refuse when it should.

The standard example is an interface that hides the delete or approve button from normal accounts, while the endpoint behind it accepts the request from anyone who is signed in. Any signed-in account can find that endpoint by watching traffic or reading the front-end code.

Why it matters

The functions most at risk are the powerful ones: creating admin accounts, changing prices, refunding orders, exporting every customer, switching features on. If an ordinary account can call them, the damage is not one record but the control of the system itself. OWASP lists this as API5 in its 2023 API top ten. It becomes a path to the entire business.

It is also easy to miss. The interface looks right, normal use works, and a review of screens finds nothing. The gap appears only when someone sends the request directly with a lower-privileged account. A scanner that only follows the interface will not find it, because the interface never offers the request.

How it shows up

You meet it where roles exist: admin and support routes, internal tools exposed by the same API, and verbs the interface never uses. Typical mistakes are checking the role only in the front end, protecting GET but not PUT or DELETE, and relying on obscure paths such as /admin/ rather than a check on the server.

Put authorisation in one place on the server, deny by default, and give each function an explicit rule. Then test: take a request from a higher role and replay it with a lower one. See BFLA, vertical privilege escalation and deny by default.