Skip to main content
Version: v1

API A5 - Broken Function Level Authorization

BFLA

What is it?​

Authorization is the process where requests to access a particular resource should be granted or denied. Authorization determines which functionality and data the logged in user (or Principal) may access.

Vertical access control mechanisms restrict access to sensitive functions based on user roles or privilege levels.

With vertical access controls, different types of users have access to different application functions. For example, an administrator might be able to modify or delete any user's account, while an ordinary user has no access to these actions.

Broken Function Level Authorization (BFLA) occurs when these controls are not properly enforced at the API layer.

This includes:

  • Privilege escalation (user gaining higher-level permissions)
  • Role bypass (accessing functions without required role/scope)
  • Vertical access abuse (user accessing admin-level operations)
  • Horizontal access abuse (same-level users invoking restricted actions on peer resources)

What are specific examples?​

  • Non-admin users accessing admin-only endpoints (e.g., /admin/deleteUser)
  • Missing role or scope validation on sensitive operations
  • Backend APIs trusting client-side role enforcement
  • Hidden or undocumented endpoints accessible without proper authorization
  • Functionality exposed via alternate routes (e.g., mobile/private APIs)
  • Misconfigured OIDC scopes allowing broader access than intended

Test case FAQs​

When is this test case applicable?​

  • API endpoints requiring authentication
  • Endpoints protected by roles or OIDC scopes
  • Sensitive operations (admin actions, configuration changes, data modification)

How does it work?​

Prerequisites​

  • Roles or scopes defined via OpenAPI spec or environment configuration
  • Authentication credentials for users across different roles/scopes
  • Optional fixtures for valid resource context (improves accuracy)

Test sequence (roles)​

  1. Validate access using an allowed role (baseline check)
  2. Attempt access using disallowed roles
  3. If any unauthorized role succeeds → BFLA detected

Test sequence (scopes)​

  • Scope-based validation follows the same pattern (planned/partial support)

Success/Failure indications​

  • Expected failures: 403 Forbidden, 401 Unauthorized
  • Some APIs may return 404 Not Found to mask authorization failures

Accurate detection improves when:

  • Valid resource fixtures are provided
  • Role-resource relationships are clearly defined

What is the solution?​

  • Enforce deny-by-default access control
  • Validate roles and scopes server-side on every request
  • Do not rely on client-side enforcement
  • Centralize authorization logic (middleware/policy engine)
  • Regularly audit role-permission mappings
  • Restrict and monitor access to sensitive/admin endpoints

References​

OWASP API TOP-10 A5
Vertical Authorization Abuse

Was this page helpful?