In November 2018, KrebsOnSecurity revealed that a US Postal Service API had been quietly exposing account data for roughly 60 million Informed Visibility users for more than a year. The root cause wasn't a stolen password or a cracked key — it was an API endpoint that let any authenticated user query, and in some cases modify, account records belonging to someone else. That's Broken Function Level Authorization (BFLA) in its purest form: a backend function meant to run only for a specific role executes for anyone who finds the URL. As more product functionality moves into APIs — mobile backends, partner integrations, internal microservices — BFLA has become one of the most common and most expensive categories of API vulnerability, formalized by OWASP as API5:2023 in its API Security Top 10. This post breaks down how BFLA happens, what it has cost real companies, and how engineering teams catch it before attackers do.
What Is Broken Function Level Authorization?
BFLA happens when an API checks who a user is but not what they're allowed to do, letting a normal user invoke a function reserved for an admin, a support agent, or another tenant. It's easiest to see next to its sibling vulnerability, Broken Object Level Authorization (BOLA, OWASP API1:2023): BOLA is about reaching someone else's data (GET /orders/1042 when order 1042 isn't yours), while BFLA is about reaching a function you shouldn't be able to call at all, regardless of whose data it touches — POST /admin/users/1042/delete or PUT /users/1042/role. A classic pattern: the web app's admin panel hides a "delete user" button from regular accounts, so the team assumes the risk is handled — but the underlying /admin/users/{id} endpoint never actually checks the caller's role on the server, meaning anyone with a valid session token and a REST client can call it directly. OWASP has kept function-level authorization in both the 2019 and 2023 editions of the API Security Top 10 because this pattern keeps recurring across frameworks and languages.
Why Do BFLA Vulnerabilities Happen?
They happen because authorization logic gets tied to what the interface shows rather than what the backend enforces. Five patterns show up repeatedly in real codebases: front-end-only gating, where a role check hides a button in React or a mobile view but the corresponding endpoint has no server-side guard; inconsistent verb handling, where GET /users/{id} is protected but PATCH /users/{id} on the same route was added later and never wired into the same middleware; API versioning debt, where a /v1/ endpoint kept alive for backward compatibility never received an authorization check that was added to /v2/; microservice sprawl, where a dozen services each reimplement their own authz middleware and one gets it wrong or skips it during a rushed release; and predictable or sequential resource IDs that turn a missing role check into an instant way to enumerate every account in the system. Any one of these is enough to turn an internal-only function into a public one overnight.
What Do Real-World BFLA Breaches Look Like?
They look like ordinary features shipped without a server-side role check, discovered either by researchers or by attackers. In January 2021, Pen Test Partners disclosed that Peloton's API let any authenticated user pull another rider's age, gender, weight, and city — even when the account's privacy toggle was set to hide that data — because the profile endpoint didn't verify whether the caller had permission to view the target's private fields; Peloton took roughly four months to fully patch it, finally closing the gap in May 2021 after press coverage forced the issue. The USPS case from November 2018 is the other frequently-cited example: the Informed Visibility API let any of the program's roughly 60 million registered users query and edit account details belonging to other users, a function that should have been restricted to account owners or admins. And in early 2022, Coinbase publicly disclosed and paid a $250,001 bug bounty for a flaw in its retail trading platform: a specific sequence of API calls let an account submit a sell order for an asset it didn't actually hold, because the balance-validation function wasn't consistently invoked across every order code path. The check existed — it just wasn't enforced on every function that needed it, which is the textbook shape of a BFLA bug.
How Common Is BFLA Across Modern APIs?
It's common enough to show up in almost every serious API security survey published in the last five years. Salt Security's State of API Security Report from Q3 2021 found that 95% of surveyed organizations had experienced a security incident in a production API in the prior twelve months, with authorization gaps consistently cited as a top root cause alongside bot abuse and misconfiguration. Gartner had already flagged the trend in 2021, predicting that API abuses would move from an infrequent to the most frequent attack vector against enterprise web applications. The underlying driver is scale: as companies decompose monoliths into dozens or hundreds of services, each with its own set of endpoints, the number of places a role check can be forgotten grows linearly with the number of routes — and most organizations don't have a reliable, up-to-date inventory of every endpoint they've shipped, which is precisely the blind spot BFLA exploits.
How Can Teams Detect and Prevent BFLA?
Prevention comes down to enforcing authorization centrally and testing every endpoint against every role, not just the ones a UI happens to expose. In practice that means: deny-by-default middleware that requires an explicit role or scope grant before any handler runs, rather than defaulting to "allow unless denied"; a single centralized policy layer (RBAC or ABAC) applied consistently across every service instead of per-team reimplementations; automated authorization matrix testing that calls every documented endpoint with every role — including no role and expired tokens — as part of CI, not just as a manual pentest exercise once a year; a live API inventory that catches "shadow" or "zombie" endpoints left behind from old versions or abandoned features, since you can't authorize what you don't know exists; and contract tests tied to the OpenAPI/Swagger spec that fail the build when a new route ships without an attached auth requirement. None of this is exotic — it's the difference between authorization as a per-developer judgment call and authorization as a property the pipeline can verify on every pull request.
How Safeguard Helps
Safeguard treats BFLA as a supply chain problem, not just an application security problem, because most of these gaps enter through the same pipelines that ship every other change: a new microservice spun up from a template that copied last quarter's auth middleware, a vendor SDK that changed its default scope behavior in a minor version bump, or a code-generated API client whose backing route never got a role check added. Safeguard continuously inventories the API endpoints defined across your repositories — including the ones nobody remembers documenting — and flags new or modified routes that lack a corresponding authorization check before the pull request merges, rather than after an incident report. It diffs authorization middleware coverage across services on every change, so a route that quietly loses its role guard during a refactor gets caught in review instead of in production. And because Safeguard is built for software supply chain visibility, it ties that authorization coverage back to the dependency and pipeline changes that introduced it, giving security and compliance teams an audit trail — useful for SOC 2 evidence and internal review alike — that shows not just that an endpoint is protected today, but what changed the last time it wasn't.