Home / Knowledge hub / Missing function-level access control
Knowledge hub
Missing function-level access control
A sensitive action that checks you are signed in but not whether you may use it.
What it means
Missing function-level access control is when a sensitive action, such as deleting a user, changing a price or exporting all records, checks that the caller is signed in but not whether their role allows it. The button may be hidden from ordinary users, yet the endpoint behind it answers anyone.
It differs from reaching someone else's record. Here the issue is the function itself: who is allowed to call it. OWASP's API list names it BFLA, and CWE calls the underlying fault missing authorisation. Fixing it means a rule on every function, not on the page that links to it.
Why it matters
An ordinary account that can call an admin function can often do the most damage in the app. It can create staff users, issue refunds, read other customers' data or change settings. These actions are often logged as normal, so the first sign is the consequence.
The flaw is easy to introduce. Admin screens are built for staff, and the team assumes only staff will find them. Then a mobile app, a new API version or a quick internal tool exposes the same function without the check.
How it shows up
You meet it in admin and back-office routes, in actions grouped under /admin or /internal, in APIs where the method can be changed (a read-only GET works, and so does DELETE), and in functions added late for support or data fixes.
To test, collect every function the app offers to staff and try each as an ordinary account, and with no session. The fix is to enforce permissions on the server in one place, applied by default, so a new route without a rule is refused, not allowed. Review admin routes and test each method.
Questions people ask
Missing function-level access control, answered
Is this the same as BFLA?
Yes, they describe the same weakness. BFLA, Broken Function Level Authorization, is the OWASP API Security name. See [[bfla]].
Why is hiding the admin button not enough?
Because the browser is not a security boundary. Anyone can call the underlying request directly. The server has to decide, not the page.
How is it different from broken object-level access?
Object-level problems are about which record you may touch. Function-level ones are about which actions you may perform at all. An app can have one without the other.
Does authentication count as access control here?
No. Being signed in answers who you are. The function must also check what you may do.
How do we find these in our own app?
List all routes and methods, mark which role should reach each, and test with accounts of lower rank. Static review of route definitions can show routes with no permission check.
Sources
Where this comes from
Related
Terms that sit next to this one
BFLA
An API lets an ordinary account call functions meant only for admins.
Broken access control
An application failing to enforce its own rules about who may do what.
Vertical privilege escalation
Climbing to a higher level of access than your account was granted.
Admin panel exposure
A management page left reachable by the public or by ordinary accounts.
Server-side authorisation
Enforcing permissions on the server, because hiding a button in the page protects nothing.
Who can call your admin functions?
We test sensitive functions with accounts of lower rank and report only what we actually reached, with the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.