Broken Function Level Authorization (BFLA)

Overview

Broken Function Level Authorization (BFLA) is an API authorization flaw that allows a user or service to invoke a function, operation, or endpoint reserved for another role or privilege level. The control exists to prevent APIs and applications from allowing unauthorized data access, privileged functions, unsafe state changes, or execution through defective design or implementation. It concerns access to functions, while object-level and object-property authorization flaws concern particular records or fields. It should be interpreted alongside Broken Object Property Level Authorization (BOPLA) because the concepts can affect the same decision without representing the same control, event, or risk.

The workflow starts with explicit trust boundaries, identities, objects, fields, functions, states, and allowed transitions. Server-side controls validate every request, use restrictive schemas, calculate authoritative values, and reject operations that violate authorization, sequence, rate, content, or business rules. In this context, every request should enforce server-side authorization using the authenticated principal, action, resource, tenant, and policy context rather than relying on hidden user-interface controls, route names, or client-supplied role claims.

It should connect the term to Access Control List (ACL) where that relationship changes access, transaction treatment, investigation, communication, or recovery.

Testing should include positive and negative authorization cases, multiple roles and tenants, malformed and replayed requests, concurrency, version changes, nested data, recovery paths, and production-like configurations. Logs should connect principal, request, resource, decision, error, and resulting state without recording secrets.

Useful measures include endpoint coverage, failed authorization tests, vulnerable versions, time to remediate, abuse attempts, error and rejection rates, recurring defect classes, and differences between specification and deployed behavior.

The relationship with API Testing should be documented where it affects residual risk or control ownership.