OWASP API Top 10 API5 Broken Function Level Authorization Guide: Protecting Admin Functions

Broken Function Level Authorization (BFLA) happens when an API lets a caller invoke an operation, such as an admin action, an export or a delete, without checking that the caller's role or permissions allow that operation. OWASP ranks it API5 in the API Security Top 10 2023 and rates its technical impact as severe, because administrative functions are the prime target and APIs make them easy to guess. This guide goes deeper than the summary in the Top 10 API Security Risks: it covers what the OWASP entry requires, how to design function-level enforcement that cannot be skipped, how service accounts and AI agents change the picture, and how to test, evidence and monitor the control. It is written for API developers, architects, application security engineers and testers.

Key takeaways

• BFLA is a vertical check on the operation. The question is whether this caller may perform this function at all, for example create an admin invite or export every user, before any question about which object it touches.
• The URL does not tell you what is privileged. OWASP warns that admin endpoints often sit beside regular ones, such as under /api/users, so classify functions by what they do, not by path.
• The HTTP method is part of the function. If GET is allowed, PUT, PATCH and DELETE on the same route need their own decision; OWASP lists method switching as a core test.
• Deny by default from one enforcement point. OWASP asks for a consistent, easy-to-analyse authorisation module invoked from all business functions, with explicit grants per role for every function.
• Machine identities need function scopes too. A service account or AI agent token that can call every operation turns any compromise or prompt manipulation into admin access.

What it is and who it applies to

OWASP describes BFLA as an attacker sending legitimate API calls to an endpoint they should not have access to, either as an anonymous caller or a regular, non-privileged user. It explains that the checks are hard to get right because modern applications have many roles, groups and hierarchies (sub-users, users with more than one role), and that APIs make these flaws easier to find because their structure is predictable.

How it differs from API1 and API3: with BOLA (API1) the caller may use the function but reaches another user's object; with BFLA the caller should never reach the function. Property-level flaws (API3) concern individual fields within an object the caller may otherwise use. See the OWASP API Top 10 API1 Broken Object Level Authorization Guide and the OWASP API Top 10 API3 Broken Object Property Level Authorization Guide. Many real incidents chain them: a missing function check on an export endpoint is also a mass object exposure.

Who it applies to: any API with more than one privilege level, which in practice is nearly all of them: customer and admin roles, tenant administrators, support staff, partner integrations and internal operations tooling. OWASP maps the risk to CWE-285 (Improper Authorization), and it is the API successor to "A7: Missing Function Level Access Control" in the OWASP Top 10 2013. The wider web equivalent is covered in the Broken Access Control Prevention Guide.

Structure and key requirements

The OWASP entry gives three diagnostic questions and four prevention requirements. Read with ASVS 5.0 and the OWASP Authorization and REST Security cheat sheets, they become the requirements below.

The three OWASP test questions, applied

• Can a regular user reach administrative endpoints? OWASP Scenario 2 is a GET /api/admin/v1/users/all route with no function check, found by an educated guess from the API's structure.
• Can changing the method grant a forbidden action? A user allowed to GET a resource should not be able to DELETE it by changing the verb. The REST Security Cheat Sheet recommends an allowlist of methods per route, 405 Method Not Allowed for anything else, and an authorisation check for the method on each collection, action and record. It also warns that verb tampering has bypassed access controls in some frameworks. Method override headers that let a POST act as a DELETE must go through the same check, or be disabled.
• Can group X reach group Y's function by guessing? OWASP's example is /api/v1/users/export_all. Bulk, export, import, impersonation and configuration operations are the usual targets.

OWASP Scenario 1 shows how small the gap can be: an invite-only app calls GET /api/invites/{invite_guid}; the attacker changes this to POST /api/invites/new, an endpoint meant only for the admin console, sets the role to admin, and uses the invite to create an administrator account. The endpoint existed and worked; it simply never checked who called it.

Designing the permission model

• Name permissions after operations: invites:create, users:export, billing:refund, mapped to roles in one place. This avoids role checks such as if role == "admin" that break when roles multiply.
• Handle hierarchy explicitly: sub-users, delegated tenant admins and users with several roles are where OWASP says checks go wrong. Write down whether a tenant admin may perform platform admin functions (normally never) and test it.
• Prefer attributes where roles explode: the OWASP Authorization Cheat Sheet recommends ABAC or ReBAC over pure RBAC for finer-grained and multi-tenant decisions and notes the problem of role explosion. See the Authorisation Models Guide.
• Apply changes immediately: ASVS V8.3.2 (L3) asks that a revoked role takes effect at once, or that mitigating controls exist where decisions rely on claims cached in self-contained tokens.

Identity and NHI requirements

Function-level authorisation is often reviewed only for human roles, while the most powerful callers are service accounts, integration clients and automation. These need the same explicit, least-privilege permissions.

• Scopes are function permissions: an OAuth scope such as users:export is a function-level grant. It only protects anything if the API checks it on every request. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
• Admin interfaces need more than a role: ASVS V8.4.2 (L3) asks for multiple layers on administrative interfaces, including continuous identity verification, device posture and contextual risk, so that network location is never the only factor.
• Default and shared admin credentials defeat the model: ASVS V6.3.2 requires default accounts to be absent or disabled; a working function check is worthless if the admin token is shared or default.

Implementation steps

1. Build the function inventory. Export every route and method from the OpenAPI or GraphQL schema and from the framework's router at runtime, then reconcile with gateway traffic. Mark each operation as public, authenticated, privileged or administrative based on what it does. See the OWASP API Top 10 API9 Improper Inventory Management Guide.
2. Write the permission matrix. Roles and machine clients as rows, operations (route plus method) as columns, expected allow or deny in each cell. This is the ASVS V8.1.1 documentation and the test oracle.
3. Enforce deny by default in the framework. Add a global middleware or filter that rejects any route without a declared permission, and make the build fail if a new route has none. Use admin base controllers or annotations for privileged functions, as OWASP suggests.
4. Externalise complex decisions. Where many services share roles, call a policy decision point with subject, action and resource and fail closed if it is unavailable. See the Policy-as-Code for Authorisation Guide.
5. Separate administrative surfaces. Serve admin APIs on a different host, audience or gateway with stronger authentication, and never rely on the client hiding admin buttons. The gateway adds a layer but does not replace the in-service check. See the API Gateway Security Guide.
6. Lock down methods. Allowlist methods per route, return 405 for the rest, and route method override headers through the same authorisation decision or disable them.
7. Roll out in audit mode. Run the new policy alongside existing checks and log disagreements for one or two release cycles, fix false denials, then enforce service by service. Keep the previous policy version deployable so a faulty rule can be reverted quickly, and never roll back to "allow all".
8. Automate regression tests. Generate one test per matrix cell and run it in CI for every role and machine client, failing the build on any mismatch.

Choosing an enforcement approach

Smaller organisations usually get the most from framework-level deny by default, a permission matrix in the repository and generated tests. Larger organisations benefit from a shared policy service and a separately hosted admin plane, because they make the rules auditable across dozens of APIs.

Evidence and assessment

• Design evidence: the function inventory with privilege classification and the permission matrix (ASVS V8.1.1).
• Test evidence: CI results for every role, client and method against every operation. The OWASP Authorization Testing Automation Cheat Sheet describes a matrix file of roles and services with the expected allowed or denied response codes, driving one integration test per role.
• Manual testing: authorised testers replay admin traffic captured from the admin console with low-privilege and machine tokens, switch methods, try method override headers and guess sibling routes. See the API Penetration Testing Guide.
• Static checks: rules that flag routes without a permission annotation and handlers that compare role strings directly.

Detection signals and metrics

See the Secure Error Handling and Logging Guide for log content that supports these signals without leaking data.

Mapping to other frameworks

NIST AC-6(10) is the closest single control statement of API5: non-privileged users must not be able to execute privileged functions. For the wider verification standard, see the OWASP ASVS Guide.

Common pitfalls

• A permission check that always says yes: in the Gravity SMTP CVE-2026-4020 case, a REST route intended for test data had a permission callback that unconditionally returned true, so anyone could call it and receive a system report containing configured API keys and tokens. Wordfence reported more than 17 million blocked exploit attempts.
• Hiding admin functions in the client: removing a button from the mobile app or SPA does nothing when the endpoint still answers, as OWASP's invite scenario shows.
• Checking GET but not the other methods: read access is checked, while PUT, DELETE or a method override header on the same route reaches the write path unchecked.
• Classifying by path: protecting /admin/* at the gateway while admin operations also live under /api/users or in GraphQL mutations.
• Trusting internal callers: back-office APIs reachable from the cluster with no authorisation, so one compromised workload has admin functions.
• Over-scoped machine tokens: integration and agent credentials given admin scopes because the right ones were hard to work out, and never reviewed.

Practitioner checklist

• Inventory every route and method, and classify each operation by privilege based on what it does.
• Maintain a permission matrix of roles and machine clients against operations, stored with the code.
• Enforce deny by default in the framework so routes without a declared permission are rejected.
• Implement admin functions through base controllers, annotations or a policy engine, never ad hoc role string checks.
• Allowlist HTTP methods per route, return 405 otherwise, and authorise method override headers or disable them.
• Serve administrative APIs on a separate surface with stronger authentication, while keeping in-service checks.
• Grant machine clients and AI agents only the scopes they need and enforce scopes per operation.
• Generate CI tests from the permission matrix for every role, client and method, failing the build on mismatch.
• Log privileged function use and alert on non-admin identities calling admin operations.
• Review admin scopes and roles held by non-human identities at least quarterly.

Standards and references

• OWASP: API5:2023 Broken Function Level Authorization
• OWASP: API Security Top 10 2023
• OWASP: Application Security Verification Standard 5.0
• OWASP Cheat Sheet Series: Authorization
• OWASP Cheat Sheet Series: REST Security
• OWASP Cheat Sheet Series: Authorization Testing Automation
• MITRE: CWE-285 Improper Authorization
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Top 10 API Security Risks · API Security Guide · Broken Access Control Prevention Guide · Authorisation Models Guide · OWASP API Top 10 API2 Broken Authentication Guide