What Is Broken Function Level Authorisation? API Security | Yrzo AI

What Is Broken Function Level Authorisation?

Broken Function Level Authorisation (BFLA) is an access control vulnerability where an application correctly restricts which data users can access but fails to restrict which actions or API functions they can invoke. A regular user can call administrative endpoints, trigger privileged operations, or access management functions simply by making the right HTTP request — because the application checks object-level permissions but not function-level permissions.

BFLA is OWASP API Security Top 10 item A5:2023. It is one of the most consistently exploited API vulnerabilities in real-world breaches, partly because it is easy to miss during development and easy to find during testing.

The Core Pattern

A typical web application has two tiers of functionality: user-facing features that all authenticated users can access, and administrative features that only specific roles should access. In a well-implemented application, both tiers check permissions on every request. In a BFLA-vulnerable application, only the UI enforces the distinction — the API endpoints underlying administrative features accept requests from any authenticated user.

**Visible to a regular user:** ``` GET /api/v1/account/me POST /api/v1/account/update-profile GET /api/v1/documents ```

**Hidden in the admin UI but accessible via direct API call:** ``` GET /api/v1/admin/users POST /api/v1/admin/users/{id}/delete POST /api/v1/admin/users/{id}/promote GET /api/v1/admin/invoices POST /api/v1/admin/config/update ```

The admin endpoints exist, they function correctly, and they return data or perform operations — but they do not verify the caller has administrative privileges. They assume only admin users will call them because the admin UI is the only place the buttons appear.

Why It Happens

The root cause is almost always architectural rather than a single mistake. Teams build the frontend and the API in parallel. The frontend enforces role-based navigation — hiding admin links from regular users. The backend is built to serve those endpoints. Somewhere in the process, the explicit assumption that "only admins see this button, therefore only admins will call this endpoint" is never challenged.

Additional contributing factors: - REST APIs where admin and user endpoints share a versioned prefix - GraphQL APIs where mutations are distinguished by name rather than by permission check - Microservices where an internal admin service is accidentally exposed through an API gateway - Endpoints added during rapid development that skip the standard authorisation middleware - Code inherited from previous developers where the authorisation design is not documented

Attack Mechanics

Exploiting BFLA requires:

1. **Enumerate endpoints** — Browse the application as a regular user. Look for API calls in browser DevTools. Review JavaScript bundles for hardcoded endpoint paths. Check `robots.txt`, API documentation, or Swagger/OpenAPI specs if exposed.

2. **Map the difference between user and admin functions** — Identify any operations visible in the frontend that suggest administrative equivalents: user management, configuration, billing, reporting.

3. **Send requests directly** — Use the authenticated session token for a regular user account and call the suspected administrative endpoints directly via `curl` or a proxy tool.

4. **Observe the response** — A 200 response with administrative data confirms BFLA. A 403 confirms the endpoint exists but is properly protected. A 404 means the endpoint does not exist at that path.

**Example:**

Regular user session token in hand. The application's admin panel is at `/admin` and is blocked for regular users by the frontend. But what is the API doing?

```bash curl -H "Authorization: Bearer user_token_here" \ https://api.example.com/v1/admin/users

# Response: { "users": [ { "id": "1", "email": "admin@example.com", "role": "admin", "passwordHash": "..." }, { "id": "2", "email": "victim@example.com", "role": "user", "card_last4": "4242" }, ... ] } ```

The regular user receives the full user database because the endpoint has no server-side role check.

Real-World CVEs and Incidents

**CVE-2020-9271 (Yii Framework admin routes)** — Certain Yii-based applications exposed administrative action routes to unauthenticated or low-privilege users due to missing controller-level access checks.

**CVE-2022-22965 (Spring4Shell context)** — While primarily a deserialization RCE, the attack chain exploited BFLA in Spring MVC's class loader manipulation — administrative-level class manipulation operations reachable by regular HTTP requests.

**Peloton API breach (2021)** — Security researchers found that Peloton's workout and user data API endpoints returned full user records for any authenticated user, regardless of whose data was being requested. Administrative query capabilities were reachable by regular user tokens.

**Experian API leak (2021)** — Experian's credit score API was found accessible to third-party lender partner sites without adequate authentication checks, exposing credit report functions to calls that should have required additional verification.

The Difference Between BFLA and BOLA

These two vulnerabilities are often confused:

**BOLA (Broken Object Level Authorisation)** — A user accesses objects belonging to another user. "I can see user ID 42's data when I should only see my own." The function (viewing profile data) is permitted; the object (another user's data) is not.

**BFLA (Broken Function Level Authorisation)** — A user accesses functions not permitted for their role. "I can call the admin delete-user endpoint when I am not an admin." The object being acted on may be theirs or others'; the function itself is not permitted for their role.

Both appear in the OWASP API Top 10. Both require server-side controls. Neither can be fixed by hiding UI elements.

Prevention

Enforce role checks at every endpoint

Every API endpoint must verify the caller's role before executing. This check should be centrally implemented — in middleware or a decorator — not duplicated across individual endpoint handlers:

```python from functools import wraps from flask import g, abort

def require_role(*roles): def decorator(f): @wraps(f) def decorated(*args, **kwargs): if not g.current_user: abort(401) if g.current_user.role not in roles: abort(403) return f(*args, **kwargs) return decorated return decorator

@app.route("/api/v1/admin/users") @require_role("admin", "superadmin") def list_users(): return jsonify(get_all_users()) ```

Separate admin and user APIs at the routing level

Rather than distinguishing admin endpoints by path prefix within a shared router, use separate routers or API versions with different middleware stacks:

```javascript // user-router.js — authenticated middleware router.use(requireAuthenticated); router.get("/account", getAccount);

// admin-router.js — admin middleware applied to ALL routes adminRouter.use(requireAuthenticated, requireRole("admin")); adminRouter.get("/users", listUsers); adminRouter.delete("/users/:id", deleteUser); ```

Deny by default

The application's authorisation model should explicitly grant access, not assume it. A new endpoint should fail closed — returning 403 — unless a permission rule explicitly grants access to the requesting role.

Test with a regular user token

During development and in automated testing, run the complete API test suite using a low-privilege user token. Any administrative endpoint that does not return a 403 for that token is a BFLA vulnerability.

How Yrzo AI Detects BFLA

Yrzo AI's scanner maps the application's endpoint structure, identifies administrative or privileged function paths (by path naming, HTTP method semantics, and response content), and probes them using standard user-level session tokens. Confirmed BFLA findings include the endpoint, the evidence of successful access, and the specific authorisation control that is missing.

[Scan your API at yrzoai.dev](https://yrzoai.dev) — results in 24 hours.