Broken Function Level Authorization (BFLA)

Overview

What it means and why it matters

Broken function level authorization occurs when an API allows a caller to invoke an operation reserved for a different role or privilege level. It often appears in admin or payout endpoints.

How it works in practice

A service may provide read-only status routes, merchant invoice creation and administrator-only settlement controls. Every route must verify the authenticated caller’s permission for that specific function, regardless of how the endpoint is named or hidden in the interface.

Technical detail without the jargon

Use deny-by-default role and permission checks server-side, plus scoped API keys for powerful actions. Test unusual HTTP methods, alternate paths and versioned endpoints to ensure an attacker cannot reach the same privileged operation through an unguarded route.

A deeper point to understand

Permissions can become inconsistent during API version changes. An admin-only endpoint may gain a new public alias without carrying over authorization middleware. Include versioned routes in security tests and design enforcement at the operation layer so a route rename cannot silently remove a critical check.

Common mistakes and limitations

An API token that can read invoice status must not be able to send merchant funds just because it knows the `/payouts/create` endpoint. Restrict permissions independently from authentication.

What to check in a real payment system

Create a permission matrix listing who may view invoices, issue refunds and change withdrawal configuration. Test each sensitive API operation under read-only, support and administrator roles. Include alternate HTTP methods and old endpoint versions to detect forgotten privileged routes.

Related concepts

Webhook, Webhook Verification, API Key.

Further reading

OWASP — BFLA.