Broken Function Level Authorization

What Is Broken Function Level Authorization?

An API confirms a caller is signed in, then runs whatever function they ask for, without checking that their role may invoke it. Privileged controls are hidden in the interface while the endpoints themselves carry no role check, so any valid token reaches them. You'll use an honest read-only analyst token to pull a full customer roster and queue a large payout, every request answered 200. Then you ship a router-level authorize('admin') guard returning 403, so the admin surface is deny-by-default and new routes inherit the check.

What You'll Learn in Broken Function Level Authorization

• Recognize broken function level authorization: a valid session reaching a privileged function because the endpoint checks who is calling but not whether their role may call it
• Distinguish it from broken object level authorization (changing an object id) and from token-forging privilege escalation (tampering with your own credential); here the token is honest and low-privilege and the function check is missing
• Understand that hiding an admin control in the UI or omitting a route from documentation is not access control, because clients call the API directly and the endpoint still answers
• Apply the fix: enforce authorization server-side on every privileged function, take the caller's role from the authenticated session rather than the request, and prefer a deny-by-default guard at the router boundary so new routes inherit the check
• Audit every admin, internal, and staff-only endpoint for a missing role check, especially where privileged and ordinary functions share one authenticated API

Broken Function Level Authorization — Training Steps

1. A read-only seat

   Fennmark runs a payments platform, and it hands out self-serve developer accounts to anyone who signs up. Bob took one, with a throwaway identity. His seat is an Analyst: read-only, sandbox-scoped, nothing sensitive. He opens the developer console to get his bearings on what his account is and what the API offers.

2. Admin functions, in plain sight

   Bob's seat is read-only, so the admin controls are hidden from him in the interface. The API reference is not hidden, though, and it lists every staff-only function right alongside the ones he is allowed to call.

3. What the token says

   Before he touches anything privileged, Bob checks what identity his own token carries. He points the API Tester at the account endpoint and sends his session token in an Authorization header, the same way the app does.

4. An honest analyst

   The server confirms exactly what Bob expected. His token is genuine, and it says plainly what he is.

5. Call an admin function

   Bob keeps the same request and the same read-only token, and changes only the resource in the URL to a function the reference marked staff-only: the full customer roster. If the API only checks that his session is valid and never checks his role, it will answer.

6. The whole roster, to an analyst

   The admin function answered. Bob's read-only sandbox token just pulled the platform's customer records.

7. Move the money

   Reading data is one thing. Bob now calls a function that changes state: the disbursement endpoint that queues a payout. He sends it with the same analyst token and points the destination at an account he controls.

8. A payout, queued by a sandbox account

   The money-moving function ran too. No admin, no approval, no special credential.

9. Knowledge check

   You just watched a read-only account read the customer roster and queue a payout. Lock in why.

10. The alert lands

    You own Fennmark's back-office API. Overnight, monitoring flagged a self-serve developer account calling staff-only endpoints. Security operations has emailed you the details.