Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Broken function level authorization in APIs: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15051
Topic starter  

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:

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

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14635
 

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:

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



   
ReplyQuote
Share: