Broken function level authorization occurs when APIs fail to enforce adequate authorization checks, allowing attackers to access or manipulate sensitive functions or data they are not authorized to. This vulnerability is common in systems where the security mechanisms depend heavily on URL paths or inconsistent role verification.

Attackers often exploit these vulnerabilities by guessing API endpoints, manipulating HTTP methods, or modifying parameters to perform unauthorized actions. Examples include accessing administrative APIs as a regular user or using a public API to perform sensitive operations like deleting data or escalating privileges.

In this lesson, you will learn how broken function level authorization vulnerabilities occur and how attackers exploit them. We'll step into the shoes of an attacker exploiting misconfigured API endpoints to escalate their privileges. Additionally, you'll learn defensive techniques and best practices to prevent such attacks.

Your friend Steve is developing his own web application. He sent out an invite to an exclusive streaming platform to a friend of his, but not you! You're pretty bummed out about not being invited but you just happened to be intercepting some packets when Steve sent out this exclusive request. Let's see what we can do.

Let’s break down what happened above to understand how broken function level authorization vulnerabilities work.

Unauthorized access through misconfigured endpoints

In the example above, the attacker exploited an administrative endpoint intended for privileged users. Due to missing or improperly configured authorization checks, the system assumed that anyone who reached the endpoint had permission to perform the requested action. This is a common oversight in API design, where developers may assume security can be enforced based solely on the endpoint’s URL structure or obscurity.

Endpoints such as /api/admin/v1/users/all or /api/invites/new should always validate the user’s role and permissions against the request, regardless of the path or method being accessed. The attacker demonstrated how HTTP method changes could bypass security controls. For example, while GET /api/invites/{invite_guid} may only retrieve information, switching to POST /api/invites/new allowed the creation of new resources. Each method should have its own unique access controls, preventing unauthorized users from exploiting less protected operations.

In the scenario, the attacker successfully created an invite with elevated privileges by exploiting the lack of server-side validation for roles. The application blindly trusted the role value ("role": "admin") in the attacker’s request without verifying whether the requester had the authority to assign such privileges.

This example demonstrates an Express route handler for creating invites. The code accepts a POST request at /api/invites/new and processes the payload containing email and role. It directly stores the invite using a database.createInvite() function.

The vulnerability lies in the absence of an authorization check. There’s no mechanism verifying whether the user making the request has the necessary privileges to create invites or assign roles. This omission allows any authenticated user, or even unauthenticated users, to perform this operation and create administrative invites. The code lacks middleware to validate roles like admin, leaving it open to abuse.

This example shows a Flask endpoint that accepts a JSON payload through a POST request at /api/invites/new. It uses the request.get_json() method to extract the payload and appends the email and role values to an invites list.

The vulnerability arises from the lack of role-based authorization. There is no check to ensure that only administrators can access the endpoint or assign roles. As a result, any user (or even attackers who discover this endpoint) can create an invite, including assigning high-privilege roles like admin. The absence of user authentication or validation compounds the risk.

In the PHP example, the server processes incoming POST requests to create new invites. It decodes a JSON payload and directly inserts the data into a database using a prepared SQL statement.

This code is vulnerable because it completely lacks an authorization mechanism. The authorize() function, which might enforce role checks, is absent in this implementation. Consequently, any user, regardless of their privileges, can exploit this endpoint to generate invites and assign roles. Moreover, the code does not enforce authentication or validate the requester’s identity, meaning that unauthenticated users can also abuse the endpoint.

This C# example illustrates a POST endpoint in an ASP.NET application. The endpoint accepts an InviteRequest object containing email and role. The Database.CreateInvite() function saves the invite to a persistent store.

This implementation is vulnerable because it lacks the Authorize attribute or any explicit role-based checks. Without verifying that the requester is an administrator, any user with access to this endpoint can create invites. This unchecked functionality can lead to privilege escalation, as attackers could generate administrative invites and gain control over sensitive functions.

This example implements a CreateInvite handler for processing HTTP POST requests. The handler decodes the JSON payload, containing email and role, into an Invite struct. The payload is then saved to a mock database (db.Create("invites", invite)).

The vulnerability stems from the lack of an authorization mechanism. The code does not validate whether the user has the right role to create invites or assign roles. This allows any user to interact with the endpoint and create unauthorized invites, including privileged roles. The absence of robust error handling also leaves room for potential abuse.

The Java example showcases a @PostMapping endpoint in a Spring application. The method accepts an Invite object and persists it using inviteRepository.save(). It does not validate the email or role fields beyond ensuring they are not null.

This implementation is vulnerable due to the lack of role validation. The endpoint does not verify whether the user making the request has permission to create invites, nor does it restrict the roles that can be assigned. Any user with access to this endpoint could escalate their privileges by creating invites with administrative roles, compromising the system’s integrity.

To protect your application against broken function level authorization, you must ensure consistent, robust authorization checks for all endpoints and methods. Below are several strategies:

Implement a centralized authorization mechanism

Adopt a single, centralized module for handling authorization across all API endpoints. This ensures consistency and minimizes the risk of missing checks in individual routes.

There are two common ways to achieve this, they should be used in conjunction:

• Implementing Role-Based Access Control: Permissions to "roles" like admin or normal_user, and then those roles are assigned to users.
• Authorization middleware (in languages like JS, Python, or Go) or filters (in frameworks like ASP.NET or Java Spring) that intercept and filter requests before they reach the endpoint. Permissions can then be assigned and viewed at a high level, such as in a routes file.

Enforce a deny-by-default policy

Once a centralized auth mechanism has been set up, configure your endpoints to deny all access by default. Only explicitly granted permissions should allow access to specific functions or endpoints. This way, it's very difficult for a developer to "forget" to assign authorization controls to an endpoint.

Verify user roles for every API action

Always verify that the user has the necessary role or group membership for the requested operation. Avoid assuming that an API endpoint or HTTP method is only accessed by authorized users

On a similar note, it's important to define roles and permissions clearly, ensuring that each function or resource has a precise access control policy based on your application’s business logic.

Use API gateways for additional security

It's possible to implement cloud-based API gateways to enforce access control policies at the network layer. Gateways can log, monitor, and block unauthorized requests before they even reach your application. This may also be an effective way to thwart resource-consumption vulnerabilities such as DoS, depending on your setup.

In Node.js, you can use middleware to enforce role-based access control (RBAC).

In this example, an authorize middleware function was introduced to enforce role-based access control (RBAC). This middleware checks the role of the authenticated user (req.user.role) and ensures it matches the required role before allowing access to the endpoint. If the user does not have the admin role, the middleware responds with a 403 Forbidden status, blocking the request.

This change addresses the vulnerability by ensuring that only authorized users can access the /api/invites/new endpoint. By centralizing authorization logic in middleware, it also improves consistency across endpoints and reduces the risk of accidentally omitting access checks in the future.

In Flask, you can use decorators for role validation.

This mitigated example uses a decorator named authorize to enforce role validation. This decorator ensures that the request.user object contains the required role (admin) before proceeding to execute the create_invite function. If the user does not meet the role requirements, the decorator returns a 403 Forbidden response.

This approach mitigates the vulnerability by explicitly validating user roles for sensitive operations. By wrapping the handler with the authorize decorator, the code ensures that only authorized users can interact with the endpoint. The decorator pattern also promotes reusability, allowing other endpoints to easily adopt similar protections.

You can implement role validation in a shared function.

The mitigated PHP code incorporates an authorize function that validates the requester’s role. Before processing the request, the function checks if the user has the admin role stored in the session ($_SESSION['user_role']). If the check fails, it halts further execution and returns a 403 Forbidden response.

This change fixes the vulnerability by introducing an explicit access control mechanism. By gating the sensitive invite creation functionality with an authorization check, the system ensures that only users with the appropriate privileges can perform the operation. This simple yet effective role validation drastically reduces the risk of unauthorized access.

Using ASP.NET, you can leverage the Authorize attribute.

In this mitigated C# example, the Authorize attribute was added to the endpoint, specifying that only users with the Admin role can access it. The Authorize attribute is part of ASP.NET’s built-in authentication framework, which integrates seamlessly with user roles and policies. If a user without the admin role attempts to access the endpoint, the framework automatically denies the request with a 403 Forbidden response.

This addition resolves the vulnerability by ensuring that access to the invite creation functionality is tightly restricted to authorized administrators. Leveraging the Authorize attribute also improves maintainability, as it centralizes role enforcement without requiring manual checks within the controller method.

In Go, role validation can be implemented as middleware.

In this Go example, an authorize middleware function was introduced to enforce role validation. This middleware intercepts incoming requests and checks the Role header for the required admin role. If the role does not match, the middleware returns a 403 Forbidden response and prevents further processing.

The middleware mitigates the vulnerability by separating access control logic from the endpoint logic. This ensures that sensitive operations like invite creation are only performed by users with appropriate permissions. Centralized role enforcement also simplifies adding similar protections to other endpoints.

In Java, you can use a filter for role validation.

The mitigated Java example uses an AuthorizationFilter to validate user roles before allowing requests to proceed. The filter intercepts HTTP requests and checks the Role header. If the user’s role is not admin, the filter blocks the request by setting the response status to 403 Forbidden.

This approach fixes the vulnerability by adding a preemptive layer of security. The filter ensures that only authorized users can access the /api/invites/new endpoint, effectively preventing unauthorized users from exploiting the functionality. Additionally, the use of a filter promotes modularity and reduces the likelihood of missed access checks in sensitive endpoints.

To deepen your understanding of API security and authorization vulnerabilities, explore the following resources:

• OWASP API Top 10: Broken Function Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/
• Snyk's Blog About OWASP API Top 10