TL;DR: Broken function level authorization lets attackers use legitimate API requests to reach functions they should not control, including administrative actions, according to Salt's analysis of API abuse patterns and a New Relic Synthetics example. The core problem is that authorization policies often assume endpoints can be judged statically, but API behaviour changes fast and can outpace fixed controls.
NHIMG editorial — based on content published by Salt: Broken function level authorization exposes hidden API privileges
By the numbers:
- Broken function level authorization has been identified as the fifth most critical threat to APIs in the OWASP API Security Top 10.
Questions worth separating out
Q: How should security teams implement function-level authorization in APIs?
A: Security teams should enforce authorization on the server side for every sensitive function, not just at the UI or gateway layer.
Q: Why do WAFs and API gateways miss broken function level authorization?
A: They usually inspect request shape, not business intent.
Q: What do teams get wrong about testing API authorization?
A: They often assume a single successful response proves the control is sound.
Practitioner guidance
- Map backend functions to explicit privilege checks Inventory every sensitive API action, including delete, update, admin, and third-party integration functions, and verify that server-side checks enforce role and context before execution.
- Test for method and parameter tampering Include GET to PUT, POST to DELETE, and body or query manipulation in API security testing so controls are validated against the actual function a request can trigger.
- Baseline behaviour per user and endpoint Track typical HTTP access patterns per API endpoint and per user, then alert on abnormal function use even when authentication tokens are valid.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of method, parameter, and body manipulation against API endpoints
- The New Relic Synthetics traffic capture and request-replay sequence used to demonstrate the flaw
- Why static positive security filters are difficult to operationalise at scale in fast-changing APIs
- Implementation considerations for continuously baselining HTTP access patterns per endpoint and user
👉 Read Salt's analysis of broken function level authorization in APIs →
Broken function level authorization in APIs: are your controls keeping up?
Explore further
BFLA is an authorization failure, not an authentication failure. The identity is known, but the application misjudges what that identity is allowed to do at the function layer. That distinction matters because many teams still over-index on session legitimacy while under-testing whether backend actions match intended privilege boundaries. Practitioners should treat function entitlement as a first-class access control problem, not a nuisance in API tuning.
A few things that frame the scale:
- Broken function level authorization has been identified as the fifth most critical threat to APIs in the OWASP API Security Top 10, according to Ultimate Guide to NHIs , Regulatory and Audit Perspectives.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when an API exposes administrative functions to the wrong user?
A: Application owners, platform teams, and security teams all share accountability because the failure sits in business logic, deployment patterns, and control validation. Frameworks such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls expect access decisions to be enforced consistently, not assumed from request validity.
👉 Read our full editorial: Broken function level authorization exposes hidden API privileges