**APIs are under attack, and Broken Function Level Authorization (BFLA) is a
major culprit.**

BFLA happens when APIs fail to enforce proper permission checks, letting users
access restricted functions. It ranks #5 on the [OWASP](https://owasp.org/) API
Top 10 (2023) and has led to breaches at companies like
[Uber](https://www.uber.com/us/en/about/), Instagram, and
[GitHub](https://github.com/).

Here’s what you need to know upfront:

- **What is BFLA?** It allows attackers to exploit API functions (not just
  individual objects) to bypass permissions.
- **Why does it happen?** Common causes include misconfigured roles,
  over-reliance on client-side controls, and flawed
  [API gateway setups](https://zuplo.com/blog/2024/12/16/api-gateway-hosting-options).
- **How to fix it?** Use tools like [Postman](https://www.postman.com/) and
  [OWASP ZAP](https://www.zaproxy.org/) to test APIs, enforce server-side
  authorization, and adopt least privilege access.

**Key takeaway:** APIs need robust, server-side authorization checks at every
function level to prevent BFLA.

Read on for detailed examples, testing techniques, and long-term strategies to
secure your APIs.

## What Is Broken Function Level Authorization?

Broken Function Level Authorization (BFLA) is a security flaw that occurs when
APIs fail to enforce proper permission checks, allowing users to perform actions
they shouldn't have access to. Unlike
[object-level issues](./2025-07-27-troubleshooting-broken-object-level-authorization.md)
that target specific API objects, BFLA focuses on entire API functions. Imagine
a scenario where someone with a visitor badge can stroll into the CEO's office
and access confidential files - this is essentially what happens when BFLA
vulnerabilities exist. The system doesn't properly verify whether the user has
the right level of access.

BFLA is listed as API5 in the
[OWASP API Security Top 10](./2025-05-07-owasp-cheat-sheet-guide.md), ranking
fifth in severity as of 2023. This vulnerability is particularly dangerous
because it allows attackers to exploit legitimate API calls to access restricted
resources, bypassing standard user permissions.

> "Complex
> [access control policies](https://zuplo.com/docs/policies/acl-policy-inbound)
> with different hierarchies, groups, and roles, and an unclear separation
> between administrative and regular functions, tend to lead to authorization
> flaws. By exploiting these issues, attackers gain access to other users'
> resources and/or administrative functions." - OWASP API Security Top 10 2019
> Report

BFLA can be thought of as a broader version of Broken Object Level Authorization
(BOLA). While BOLA focuses on individual API objects, BFLA targets overarching
API functions, making its potential impact even greater. APIs are particularly
vulnerable because their structured nature often makes it easier for attackers
to identify and exploit flaws.

### How to Identify BFLA

Spotting BFLA vulnerabilities requires a keen eye for unusual API behavior. One
of the clearest signs is when users can access functions or endpoints that
should be restricted based on their role or permission level.

Some common red flags include:

- Users accessing administrative endpoints or functions meant for higher
  privilege levels.
- Bypassing role restrictions by changing HTTP methods, like switching from
  `GET` to `POST`.
- Successful API calls to endpoints that should require elevated permissions.
- Unauthorized actions, such as creating, modifying, or deleting resources.

Attackers often reverse engineer client-side code or intercept application
traffic to uncover these vulnerabilities. For example, during security testing,
a simple change in an HTTP method or endpoint parameter might reveal
unauthorized access to sensitive functions. This happens when APIs rely too
heavily on client-side controls or lack robust server-side authorization checks.
Recognizing these warning signs is critical because attackers frequently exploit
these flaws in real-world scenarios.

### Common Attack Examples

Take the example of an Invitation Hijack Attack. In this scenario, an
application that requires an invitation to join uses the following API call to
retrieve invitation details:

```
GET /api/invites/{invite_guid}
```

An attacker, however, manipulates the request by changing the method to `POST`
and targeting a different endpoint:

```
POST /api/invites/new
```

This endpoint, meant only for administrators, allows the attacker to send a
payload like this:

```
POST /api/invites/new
{ "email": "attacker@somehost.com", "role": "admin" }
```

If proper authorization checks are missing, the attacker can create an
administrative invitation for themselves, effectively taking over the
application.

Real-world examples highlight how damaging BFLA can be. For instance, breaches
at a state insurance department and a major telecommunications provider involved
attackers exploiting these vulnerabilities. In another case,
[New Relic](https://newrelic.com/) Synthetics faced a privilege escalation issue
where restricted users could modify alerts on monitors without proper
permissions.

These types of attacks pose serious risks to businesses, including data
exposure, data loss, corruption, and service interruptions. These examples
emphasize just how critical it is to perform rigorous testing to identify and
address BFLA vulnerabilities.

## Why Function Level Authorization Breaks

To secure APIs effectively, it’s crucial to understand why function level
authorization often fails. These failures usually arise from poor design and
flawed implementations. According to OWASP's 2021 findings, 94% of applications
were tested for some form of broken access control, with a 3.81% incidence rate
for such issues. This places broken access control as the **#1 application
security risk**. Let’s dive into the specific misconfigurations that weaken
function level authorization.

### Role Permission Setup Errors

Errors in Role-Based Access Control (RBAC) are a frequent cause of function
level authorization vulnerabilities. These issues arise when roles are
misconfigured, hierarchies are poorly designed, or access to specific functions
is not properly restricted. Missteps like overly broad permissions or
inconsistent role structures can result in users gaining more access than
intended, leaving critical functions exposed.

Real-world examples highlight the consequences of these errors. For instance, in
2022, GitHub faced a privilege escalation bug that allowed users to gain
unauthorized access to higher-level repository functions. A common culprit is
the failure to follow the principle of least privilege - starting users with
minimal permissions and granting additional access only when necessary.
Overlooking this principle creates exploitable gaps in backend functions or
APIs.

### Trusting Client-Side Controls

Another major vulnerability lies in misplaced trust in client-side controls.
Relying on mechanisms like JavaScript validation, hidden form fields, or
disabled buttons for enforcing access controls is a risky practice. These
client-side methods can be easily bypassed by users, as everything on the client
side is under their control.

Access control decisions must always be enforced on the server, where they
cannot be tampered with. CWE-602 specifically warns against delegating security
enforcement to the client. While client-side validation can help catch simple
errors and provide immediate feedback, it should only complement server-side
controls, never replace them.

### API Gateway Configuration Problems

Misconfigured API gateways are another common source of function level
authorization weaknesses. According to OWASP, security misconfiguration ranks as
the fifth most common API vulnerability risk. Problems like default settings,
insufficient CORS protection, missing authentication, and exposed admin APIs can
all lead to unauthorized access.

The impact of these misconfigurations can be devastating. For example, in late
2022, [T-Mobile](https://www.t-mobile.com/) suffered a data breach that exposed
the personal information of 37 million customers due to a misconfigured API with
inadequate authorization settings. Around the same time,
[Optus](https://www.optus.com.au/) experienced a breach affecting 10 million
customer accounts because an API endpoint didn’t require credentials.

> "In the instance where a public API endpoint did not require authentication,
> anyone on the internet with knowledge of that endpoint URL could use it."
>
> - Corey J Ball, Senior Manager of Cyber Security Consulting for Moss Adams

Common gateway misconfigurations include improper CORS settings, excessive
access permissions, lack of rate limiting, and missing request validation.
Exposed admin APIs and absent firewall rules further widen the attack surface.
Modern API gateway setups are often complex, and when multiple teams manage
different components, inconsistent policies and overlooked security settings can
create persistent vulnerabilities for attackers to exploit.

## How to Find and Fix Authorization Problems

Once you've identified potential BFLA (Broken Function Level Authorization)
vulnerabilities, the next step is tackling authorization weaknesses head-on.
This requires a blend of technical tools and a hacker's mindset - thinking about
how an attacker might exploit your system to access functions meant for
higher-privilege users. The trick? Simulate real-world attack methods and test
thoroughly.

### Using [Postman](https://www.postman.com/) and [OWASP ZAP](https://www.zaproxy.org/) for Testing

![Postman](https://assets.seobotai.com/zuplo.com/683b9a950194258b64ab37de/5a5edbf1eca33d130fb003bacc34136e.jpg)

To uncover authorization flaws, leverage powerful tools like **Postman** and
**OWASP ZAP**.

Postman is a great starting point for manual testing. Begin by documenting your
API endpoints and testing them with tokens from different user roles.
Specifically, capture requests made by privileged users and replay them using
lower-privilege tokens. This mirrors how attackers might attempt to access
restricted functionality that isn’t visible in the user interface.

For automated testing, **OWASP ZAP** steps in with advanced features. Its active
scanner can test combinations of headers and tokens, helping identify endpoints
that bypass proper authorization checks. It’s particularly effective at
uncovering endpoints vulnerable to unauthorized access.

Take, for example, a 2018 case where cyber researcher Jon Bottarini found a flaw
in New Relic Synthetics. He discovered that a restricted user could modify
alerts on monitors without proper permissions. Using
[Portswigger Burp Suite](https://portswigger.net/burp), he intercepted
privileged session traffic and manipulated API requests to expose hidden
vulnerabilities. This highlights how intercepting and replaying requests can
shine a light on authorization issues.

### Checking Tokens and Server Logs

**JWT (JSON Web Token) analysis** is another crucial step in authorization
testing. Decode the token payload and verify that its claims accurately reflect
the user's role and permissions. Pay close attention to fields like `aud`
(audience), scopes, and any custom permission claims.

A common problem arises when tokens are formatted correctly but carry incorrect
permissions for the requested function. Improper scope verification is often at
the root of such issues.

**Server logs** can also uncover patterns that automated tools might miss. Look
for unusual activity, such as non-admin users attempting to access admin
endpoints or users performing actions outside their normal behavior.
Standardizing log formats with key-value pairs makes analysis easier. Ensure
logs capture essential details like user IDs, event categories, outcomes, and IP
addresses.

In 2020, [Datadog](https://www.datadoghq.com/) emphasized the importance of
monitoring authentication logs to identify security threats. They suggested
tracking failed login attempts from a single user within short timeframes to
detect brute force attacks, as well as monitoring logins from multiple user IDs
originating from the same IP address to catch credential stuffing attempts.

> "An API log is a comprehensive record generated by an API that documents all
> the requests sent to and responses received from the API." - Daniel Olaogun,
> @Merge

Tools like Datadog or the [ELK Stack](https://www.elastic.co/elastic-stack) are
invaluable for collecting and analyzing API logs. Establishing baselines for
typical HTTP access patterns - both per endpoint and per user - allows you to
spot deviations that might signal an authorization bypass. From there, test edge
scenarios to further challenge your API's defenses.

### Testing Edge Cases

Edge case testing is where you’ll often find the hidden cracks in your
authorization logic. These scenarios explore how your API behaves under rare or
unexpected conditions, which is often where vulnerabilities lurk.

Start by testing token lifecycle scenarios, such as expired tokens, revoked
permissions, or modified claims. For multi-tenant systems, try using a valid
token from one tenant to access resources in another. Also, test boundary values
at the edges of your role hierarchy or system ranges.

Other edge case tests include using corrupted tokens or omitting essential
headers to ensure your system fails securely. For example, entering special
characters in user roles can disrupt authorization logic if the system doesn’t
handle these inputs properly. Similarly, feeding the system extreme input
values - like unusually large user IDs - can reveal flaws or even crash the
system if validation is inadequate.

## How to Fix API Authorization Issues

Once you've identified vulnerabilities using tools like Postman, OWASP ZAP, and
log reviews, the next step is addressing these issues. Rather than treating
security as an afterthought, it's essential to integrate authorization directly
into the API design and deployment process. Here's how to do it effectively.

### Setting Function-Level Rules with [OpenAPI](https://www.openapis.org/)

OpenAPI specifications are a powerful way to define and enforce authorization
rules at the function level. By embedding security directly into your API
documentation, you create a single source of truth that both developers and
security tools can rely on.

To start, define your security schemes in the `components/securitySchemes`
section of your OpenAPI document. OpenAPI supports several types of
authentication and authorization schemes, including HTTP, `apiKey`, `oauth2`,
and `openIdConnect`, each with its specific properties.

After defining the security schemes, apply them using the `security` keyword.
You can do this at the root level to cover the entire API or at the operation
level for more granular control. This setup allows you to safeguard sensitive
functions while keeping public endpoints accessible.

For OAuth 2 and OpenID Connect, scope-based permissions offer a detailed way to
manage access. This ensures that only users with the correct privileges can
perform administrative tasks, aligning with best practices for integrating
security into OpenAPI.

The real strength of OpenAPI lies in its ability to combine multiple
authentication types using logical OR and AND operations in the security
section. This flexibility supports different client types while maintaining
strict authorization controls, helping to prevent Broken Function Level
Authorization (BFLA) vulnerabilities.

### Choosing Between RBAC and ABAC

Once you've defined your authorization rules, the next step is selecting the
right access control model. The choice between Role-Based Access Control (RBAC)
and Attribute-Based Access Control (ABAC) significantly impacts both security
and operational complexity.

- **RBAC**: Assigns permissions based on predefined roles. It's straightforward
  to set up and works well for small to medium-sized organizations with clear
  hierarchies.
- **ABAC**: Provides finer control by using attributes like user roles,
  location, or time of access. While more complex to configure initially, it
  scales better for larger organizations with more nuanced access requirements.

Smaller organizations often start with RBAC due to its simplicity. However, as
companies grow and require more granular access controls, maintaining RBAC can
become cumbersome. ABAC, on the other hand, offers the flexibility needed for
diverse and evolving scenarios.

A hybrid approach can be particularly effective. Use RBAC for broad user
categories and ABAC for more sensitive operations that require contextual
decision-making. This combination creates robust authorization controls that
help prevent BFLA vulnerabilities.

#### Implementing RBAC

Here's a tutorial on how to implement RBAC on your API using Zuplo. There's also
a
[written version](./2025-01-28-how-rbac-improves-api-permission-management.md).

<YouTubeVideo videoId="Xo02a8rzQKc" />

### Adding Authorization Tests to CI/CD

Integrating authorization testing into your
[CI/CD pipeline](https://zuplo.com/docs/articles/custom-ci-cd) ensures that
vulnerabilities are caught before they reach production. This proactive approach
addresses issues when they are cheaper and easier to fix.

Despite its importance, many organizations lag in this area. For example, a 2024
[GitLab](https://about.gitlab.com/) survey revealed that only 29% of companies
fully integrate security into their DevOps processes. Meanwhile,
[IBM](https://www.ibm.com/)'s 2023 report highlighted that the average cost of a
breach has climbed to $4.88 million.

To avoid these risks, make security a continuous effort. Use tools like
[Newman](https://support.postman.com/hc/en-us/articles/115003703325-How-to-install-Newman)
(to run Postman collections) or OWASP ZAP for automated scanning to verify that
your authorization rules work as intended across various user roles and
scenarios.

Set clear thresholds for blocking builds when critical authorization
vulnerabilities are detected. Lower-severity issues can pass with alerts, but
critical flaws should halt deployment. Treat authorization policies as
first-class code by implementing unit and integration tests, and maintain
detailed logs of every authorization decision. This approach not only catches
vulnerabilities early but also lays the groundwork for long-term security,
reducing the risk of BFLA attacks.

## Building Long-Term Authorization Security

Strengthening API security for the long haul requires more than quick fixes. It
demands a strategic approach that adapts to your organization’s needs and the
ever-evolving threat landscape. The idea is to weave security practices into
your development process, making them a natural part of your workflow rather
than an afterthought.

### Using Least Privilege Access

The principle of least privilege is a cornerstone of effective authorization
systems. By limiting access rights to only what’s necessary, you significantly
reduce the potential attack surface. This isn’t just theory - **removing local
admin rights and controlling execution can mitigate 75% of Microsoft’s critical
vulnerabilities**. That’s a statistic you can’t afford to ignore.

Start by conducting a privilege audit to identify unused accounts, shadow admin
credentials, and outdated permissions. Transition all users to standard
privileges by default, granting elevated access only when absolutely necessary.
For high-risk API functions, implement time-bound privileges - temporary
permissions granted for specific tasks. This approach ensures that
administrative access isn’t left open indefinitely.

Hardcoded credentials should be replaced with API-based authentication systems
that can be monitored and revoked instantly. This not only improves security but
also provides better control over who has access to what, and when.

> "Authorization issues are typically difficult to detect in an automated
> fashion. The structure of the codebase should be set up in a way that it is
> difficult to make authorization errors on specific endpoints. To achieve this,
> authorization measures should be implemented as far up the stack as possible.
> Potentially at a class level, or using middleware." – Hakluke and Farah Hawa

As organizations scale, managing access becomes exponentially complex,
especially with machine identities growing at twice the rate of human
identities. This makes implementing and maintaining least privilege access a
critical step in long-term security planning.

### Managing Policies with GitOps

GitOps offers a systematic way to manage authorization policies by treating them
as code stored in Git repositories. This approach provides a single source of
truth, enabling version control, automated deployments, and quick rollbacks when
needed.

The benefits of GitOps shine during crises. For instance, when
[Weaveworks](https://github.com/weaveworks) faced a system outage caused by a
risky change, they restored their entire system - including clusters,
applications, and monitoring tools - in just 40 minutes, thanks to their
Git-based configuration files.

> "GitOps is a set of best practices encompassing using Git repositories as the
> single source of truth to deliver infrastructure as code." – Hossein Ashtari

To ensure security, use pull requests for all changes to API access controls.
This creates an audit trail and allows for automated reviews. Role-based access
control can also be integrated into your GitOps workflow, defining who has
permission to make changes to specific parts of your API configuration.

Even small adjustments to permissions should go through feature branches,
ensuring proper review and testing before deployment. Automated testing for API
configurations can catch errors early, preventing them from becoming
vulnerabilities.

By separating API code from configuration releases, GitOps allows for faster
updates and bug fixes while maintaining strict security oversight. If something
goes wrong, you can quickly roll back changes without disrupting the application
itself. This method also integrates seamlessly with CI/CD pipelines, reinforcing
security at every stage.

> "With GitOps, you can implement continuous deployment from any environment
> without having to switch tools. It's self-documenting, as changes are all
> recorded in the repo." – Cerbos

Regular policy reviews complement this automated approach, ensuring that your
security measures remain effective over time.

### Regular Permission Reviews

Even the most well-designed authorization systems can drift without ongoing
maintenance. Human error and stolen credentials remain leading causes of
security breaches. Regular permission reviews are essential to prevent privilege
creep and ensure that access rights align with current needs.

For most organizations, quarterly reviews are sufficient, but environments with
higher security demands may require monthly audits. These reviews should examine
not just user permissions but also API calls and the privileges granted to
automated systems.

Key areas to focus on include removing access for former employees, revoking
temporary privileges that have outlived their purpose, and ensuring that current
employees don’t retain permissions from previous roles. **In 2024, 61% of
organizations reported cloud security issues**, underscoring the importance of
thorough permission reviews.

Involve multiple stakeholders in the process - not just the security team.
Employees and managers who understand the business context behind access
requirements can provide valuable insights. Document every step of the review
process to create a record that supports continuous improvement.

Between formal reviews, continuous monitoring can help catch issues like failed
login attempts or unusual access patterns. This proactive approach complements
scheduled reviews and helps identify problems before they escalate.

The goal isn’t to achieve perfect security - it’s to build a system that evolves
and improves over time. Regular permission reviews create the feedback loop
necessary for continuous improvement, helping you address issues before they
turn into costly mistakes.

## Conclusion: Better API Security Through Proper Authorization

Broken Function Level Authorization (BFLA) continues to pose a serious risk.
Recent data reveals that 41% of organizations have faced an API security
incident, with 63% of these incidents leading to data breaches - even though 90%
already had authentication policies in place. This highlights a critical gap:
while authentication may be in place, effective authorization controls are often
lacking, leaving room for BFLA vulnerabilities to flourish.

Real-world cases show that no organization is completely safe from BFLA. Its
combination of being hard to detect and easy to exploit makes it particularly
dangerous.

Addressing this requires embedding robust authorization checks into every layer
of your API architecture. Every API endpoint must enforce authorization by
verifying user identity, roles, and permissions before granting access to
sensitive functions or data. This goes beyond simply implementing Role-Based
Access Control (RBAC) or Attribute-Based Access Control (ABAC) - it’s about
adopting a mindset where security is treated as a core part of development, just
like writing clean, efficient code.

Incorporating tools such as Postman and OWASP ZAP into your CI/CD pipeline can
help ensure that authorization checks are consistently validated.

For long-term protection, strategies like enforcing the principle of least
privilege,
[managing policies through GitOps](https://zuplo.com/blog/2024/07/19/what-is-gitops),
and conducting regular reviews of your authorization configurations are
essential. These practices, combined with the testing and role configuration
methods discussed earlier, create a stronger defense against threats.

BFLA is ranked #5 on the OWASP API Top 10. By implementing thorough
function-level validation, maintaining server-side authorization controls, and
adopting a zero-trust approach to API access, you’re not just patching
vulnerabilities - you’re building systems designed to handle both current and
emerging threats.

Use the techniques outlined in this guide as a starting point, and remember: API
security is an ongoing process that demands constant vigilance and improvement.

## FAQs

### What steps can organizations take to prevent Broken Function Level Authorization (BFLA) vulnerabilities in APIs?

## Preventing Broken Function Level Authorization (BFLA) in APIs

Protecting APIs from **Broken Function Level Authorization (BFLA)**
vulnerabilities requires a focus on well-implemented access controls and
diligent security testing. Start by ensuring that every API function has strict,
role-based authorization checks in place. These checks should prevent
unauthorized users from accessing sensitive operations and must be applied
consistently across all API endpoints.

Regular security assessments are equally important. Use tools like security
scanners or conduct manual testing to uncover vulnerabilities before attackers
can exploit them. Additionally, stay informed about the latest security
practices, such as those outlined in the OWASP guidelines. By continuously
reviewing and improving your authorization processes, you can strengthen your
API's defenses and reduce the risk of breaches.

### How can I identify if my API has Broken Function Level Authorization (BFLA) vulnerabilities, and what are the best ways to detect them?

## Broken Function Level Authorization (BFLA)

BFLA vulnerabilities occur when users gain access to restricted functions or
data by manipulating API requests. For instance, if altering a request parameter
allows someone to access sensitive operations or resources they shouldn't,
that's a clear sign of a BFLA issue. Another red flag is when access controls
are inconsistent or missing across various API endpoints.

To identify these vulnerabilities, start by thoroughly reviewing your API's
authorization logic. Use tools to simulate unauthorized access attempts and
analyze the results. Combining manual code reviews with automated security
testing can be particularly effective. Detailed logging of access patterns also
helps in spotting potential weaknesses. Tools like **Postman** and **OWASP ZAP**
are great for crafting test requests and examining responses to pinpoint gaps in
your authorization setup. API gateways like Zuplo help you implement fixes at
scale. Taking these steps can go a long way in strengthening your API's
security.

### Why should authorization testing be part of your CI/CD pipeline, and what tools can help?

Incorporating **authorization testing** into your CI/CD pipeline is a smart way
to identify security vulnerabilities early, ensuring that sensitive functions
are only accessible to authorized users. By addressing these issues proactively,
you can reduce risks, block unauthorized access, and maintain compliance with
security standards. In the fast-paced world of CI/CD, relying solely on manual
testing can leave gaps, but automated testing provides consistent and dependable
results.

Tools like **OWASP ZAP** are excellent for dynamic application security testing,
while [**SonarQube**](https://www.sonarsource.com/products/sonarqube/) and
[**Checkmarx**](https://checkmarx.com/) specialize in static security testing.
These tools integrate seamlessly into your pipeline, automating checks and
enabling you to catch and resolve issues quickly - before they ever make it to
production.