Insufficient function level authorization

An administrator function that does not appear in the menu is unfindable for an ordinary user, until someone opens the JavaScript bundle in which all of the application’s routes sit neatly listed. From that moment the difference between an ordinary user and an administrator is only whether the server refuses the request. Making sure it does is the whole job.

What is function level authorization?

Every application has functions not intended for everyone: managing users, assigning roles, running exports, changing settings, deleting data. Function level authorization is the check establishing whether the requester may perform this specific action.

Insufficient function level authorization, internationally broken function level authorization or BFLA, means that check happens only in the interface. The button is not shown, the menu item is absent, the route is not in the navigation. But the endpoint exists, is reachable, and executes what it is asked as soon as someone sends the request directly.

The mistake is assuming the frontend is a gatekeeper. It is not: it is a display. What a user sees is decided by the frontend; what a user can do is decided solely by the server. Picture a lift with the button for the executive floor taped over. As long as nobody thinks to remove the tape, it works. But the button is still there, and it still functions.

How is broken function level authorization exploited?

Vulnerable:

// Logged in, but no check on the role
app.post('/api/admin/users/:id/role', requireLogin, async (req, res) => {
  await users.setRole(req.params.id, req.body.role);
  res.json({ ok: true });
});

In the interface this endpoint is only reachable from an admin screen that ordinary users never see. But the endpoint itself asks only for a valid session. An attacker finds the address in the frontend bundle:

// In the application's JavaScript, visible to everyone
const routes = {
  profile: '/api/profile',
  manageUsers: '/api/admin/users',
  changeRole: '/api/admin/users/:id/role',
};

And then sends, with their own ordinary account:

POST /api/admin/users/4471/role HTTP/1.1
Cookie: sid=<own valid session>
Content-Type: application/json

{"role":"administrator"}

HTTP/1.1 200 OK

They have just made themselves an administrator. No password was guessed, no injection performed and no session stolen; one request was sent to an endpoint that served them politely.

Safe:

// Authorisation per route, explicitly recorded
const requireRole = (...roles) => async (req, res, next) => {
  const user = await users.find(req.user.id);   // current role
  if (!user || !roles.includes(user.role)) {
    await auditlog.write('authorisation denied', {
      user: req.user.id, route: req.originalUrl,
    });
    return res.sendStatus(404);
  }
  next();
};

app.post('/api/admin/users/:id/role',
  requireLogin,
  requireRole('administrator'),
  async (req, res) => {
    await users.setRole(req.params.id, req.body.role);
    res.json({ ok: true });
  },
);

// Safety net: every route without explicit rights is refused
app.use('/api', (req, res) => res.sendStatus(404));

The check now sits on the route itself and uses the current role from the database rather than a value from the session. The safety net at the end matters just as much: a new endpoint where the developer forgets the authorisation therefore closes rather than opens. That is the difference between a mistake noticed during testing and a mistake that becomes a vulnerability in production.

What is the impact of broken function level authorization?

The severity is high to critical, because the outcome usually amounts to elevating one’s own privileges. A user who can make themselves an administrator thereby gains access to everything the application offers.

Even without that direct route the consequences are considerable. Admin functions are by definition the functions with the widest reach: exporting all customer data, deleting records, changing settings that affect security, disabling two-factor authentication for other accounts. One unprotected endpoint from that category is enough for a substantial incident.

What makes it hard to establish afterwards is that everything looks normal. The attacker uses their own valid account, the request is correctly formed and the response is a 200. Without logging of authorisation decisions there is no trace showing that someone called a function not meant for them.

How do you detect broken function level authorization?

A tester first maps all endpoints, and deliberately looks beyond what the interface shows. The frontend JavaScript bundle is the richest source here: it often contains all routes, including those of admin screens. API documentation, older versions and predictable naming are used as well.

Every endpoint found is then called with an account holding minimal rights. If the request succeeds, the finding stands. Each method is tested separately, because authorisation is sometimes present on GET and not on POST or DELETE. The classic detours are tried too: a different spelling of the path, an older API version leading to the same functionality, or a header carrying a role the application wrongly trusts. AssistSec runs this test with accounts in every available role, because the interesting gaps usually sit not between anonymous and logged in but between two levels of logged-in users.

How do you prevent broken function level authorization?

• Check on the server for every endpoint whether the user may perform the associated function.
• Refuse by default and permit only explicitly, so a forgotten check leads to a refused request.
• Group admin functions under their own path with one central role check.
• Fetch the role from the database on every request, not from the session or a token.
• Test every HTTP method separately; authorisation is often missing on one of them.
• Treat hiding buttons and menu items as presentation, never as security.
• Remove or shield older API versions, because those often lack the newer checks.
• Do not trust any role or rights sent along in a header or parameter.
• Log denied authorisation attempts, so reconnaissance by a logged-in user becomes visible.