Broken function level authorization exposes hidden API privileges

At a glance

What this is: This is an analysis of broken function level authorization in APIs, showing how attackers can manipulate valid requests to reach hidden administrative functions.

Why it matters: It matters because IAM, PAM, and application security teams need controls that evaluate function-level access dynamically, not just whether a request looks syntactically valid.

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.

👉 Read Salt's analysis of broken function level authorization in APIs

Context

Broken function level authorization is a failure in how an API decides which functions a caller can reach, even when the request itself is structurally valid. In identity terms, the problem is not authentication but authorization drift: the caller is known, yet the application lets that identity invoke actions beyond its intended role or hierarchy. For teams running IAM, PAM, and application access controls, this is a control-plane problem as much as an API problem.

Modern cloud-native applications make this easier to miss because they expose many roles, user hierarchies, and endpoint paths, while the HTTP traffic remains predictable. Attackers can reverse engineer client behaviour, intercept traffic, and reuse legitimate requests against functions that should be restricted. That means static perimeter thinking is not enough when the real control boundary lives inside the application and its function mapping.

For practitioners, the key issue is that function access must be validated continuously against user context, endpoint, and intended action. The article’s New Relic example is a useful reminder that visible UI permissions and actual backend function permissions can diverge, which is typical in distributed application environments.

Key questions

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. That means mapping roles to specific actions, validating the caller’s entitlement at execution time, and testing whether a valid session can still reach restricted methods, parameters, or hidden endpoints.

Q: Why do WAFs and API gateways miss broken function level authorization?

A: They usually inspect request shape, not business intent. A request can be syntactically valid and still be unauthorized if the application fails to verify that the caller may perform the function. That is why API gateways need application-layer authorization context and behavioural baselines, not only positive filters.

Q: What do teams get wrong about testing API authorization?

A: They often assume a single successful response proves the control is sound. In practice, authorization failures appear across object IDs, scope changes, role transitions, and alternate workflows. Good testing must try the same action under different identities and permissions to see whether the API leaks access through unexpected paths.

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.

Technical breakdown

How broken function level authorization differs from object level authorization

Broken object level authorization, or BOLA, occurs when an attacker accesses a specific object they should not see, such as another user record. Broken function level authorization, or BFLA, sits one level higher: the attacker reaches an entire function they should not be able to invoke, such as delete, create, or administrative update operations. In practice, BFLA is often easier to weaponise in APIs because a valid method, token, and endpoint can still be enough to trigger a privileged backend action if the application fails to re-check function entitlement.

Practical implication: map backend functions to explicit privilege checks, not just to authenticated sessions.

Why predictable API traffic makes BFLA hard to spot

API calls are often structured, repeatable, and easy to manipulate. Attackers can change methods, parameters, or message-body values while keeping the request legitimate enough to pass syntax checks or gateway inspection. In distributed architectures, this is especially risky because client-side code, intercepted traffic, and hidden endpoints can reveal function names even when documentation is sparse. The weakness is not just exposure, but the fact that the request still looks like normal API use unless the application understands who is allowed to perform that function.

Practical implication: test for method tampering, parameter tampering, and hidden endpoint abuse during API security reviews.

Why WAFs and API gateways miss function-level abuse

WAFs and API gateways are good at filtering known bad patterns, but they do not inherently understand application intent. If a request is syntactically valid, they may pass it through even when the caller should never reach that function. Static allowlists can help, but they are difficult to maintain in fast-moving APIs and can break business workflows if over-restrictive. The deeper issue is that function-level authorization is a business rule embedded in application logic, not a perimeter rule that can be enforced reliably without context.

Practical implication: pair perimeter controls with application-layer authorization checks and continuous behavioural baselining.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate API session into unauthorized administrative capability without triggering obvious access-denied responses.

1. entry: An attacker obtains a valid session or legitimate API access and studies application traffic to discover callable functions and hidden endpoints.
2. escalation: The attacker manipulates the request method, parameters, or body content to invoke a function reserved for a higher-privileged role.
3. impact: The attacker performs administrative actions such as deleting records, changing alerts, creating accounts, or taking over functionality outside the intended access level.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Continuous baselining is the right control shape for dynamic APIs. Static filters struggle when endpoints, methods, and payloads change frequently, which is normal in cloud-native delivery. The governance problem is not simply blocking bad traffic, but understanding what normal looks like per user and per endpoint so the application can detect when a legitimate caller is trying to perform an illegitimate function. Teams need baseline-driven enforcement, not only signature-driven inspection.

Hidden functions create governance blind spots in distributed systems. When UI exposure and backend capability diverge, security teams can believe an action is unavailable simply because it is not visible in the front end. That assumption breaks as soon as a caller can discover and invoke the function directly. The practical implication is that access reviews must include backend function exposure, not just interface-level entitlements.

Function-level authorization gaps expand the identity blast radius. A single broken control can convert a normal user session into administrative reach, which is why BFLA sits in the same operational risk class as privilege escalation. The named concept here is the function access mismatch: the gap between what an identity can see and what it can actually execute. Practitioners should measure that mismatch explicitly because it is where API abuse becomes identity abuse.

From our research:

• 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.
• From our research: 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.
• For the broader governance model: Review Top 10 NHI Issues to see how identity control gaps compound across machine and application access.

What this signals

Function access mismatch: teams should treat visible permissions and executable permissions as separate governance layers, because API abuse often begins where those layers diverge. In practice, that means access review evidence must include backend function reachability, not just user interface entitlements, and it should be aligned with NIST Cybersecurity Framework 2.0.

The most durable programmes will baseline function use continuously rather than rely on static allowlists alone. That shift matters because API behaviour changes quickly, and a request that once looked normal can become privileged through role drift, hidden routes, or integration sprawl.

For teams already managing machine access, the lesson is broader than APIs: function-level drift is another form of identity blast radius. Linking application authorization reviews to the NIST SP 800-53 Rev 5 Security and Privacy Controls gives audit teams a clearer way to test whether access is actually constrained at execution time.

For practitioners

• 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.
• Review hidden backend exposure during access reviews Go beyond UI permissions and confirm which API functions remain reachable to non-privileged users, third parties, or deprecated integrations.

Key takeaways

• Broken function level authorization lets valid API requests reach privileged functions that should stay out of reach.
• The control gap is operational, not theoretical, because predictable request structures make function abuse hard for gateways to distinguish from normal traffic.
• Teams need server-side authorization checks, function-level baselines, and testing for method or parameter tampering to reduce the blast radius.

Key terms

• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• Function Access Mismatch: The gap between what an identity can see in an interface and what it can actually execute in the backend. In API security, this mismatch is dangerous because attackers can discover functions through traffic analysis, then manipulate requests to trigger actions that should be restricted.
• Runtime Behaviour Baseline: The expected pattern of activity for an identity while it is operating in production. It goes beyond entitlement lists by comparing actual actions, timing, and access paths, which is critical when valid credentials can still be abused.

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

👉 Salt's full post covers the New Relic example, request manipulation details, and baseline detection approach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.