OWASP Top 10 API security risks: Broken function level authorization

Number five on the list of the Open Worldwide Application Security Project® (OWASP) Top 10 API Security Risks is broken function level authorization.

Broken functional level authorization (BFLA) occurs when endpoints are exposed to non-authorized users.

Attack  vectors

Attackers send legitimate API calls to an endpoint they should not be able to access. These calls might come from anonymous users or regular users that should not have privileges for access.

When endpoints are exposed, exploitation is easy for threat actors. Because API calls are generally structured, threat actors can make small modifications to strings in a predictable way. This attack is similar to broken object level authorization (BOLA) exploits, but in this case, attackers focus on API functions instead of API objects. Often, both types of attacks are used in combination to probe security.

Security weaknesses

Improperly implemented or misconfigured authorization can lead to security flaws. This is surprisingly common as API endpoints are often part of a complex infrastructure and contain a large number of users, groups, and roles, including users with multiple roles. Cloud-native designs and distribution architecture can make this especially complicated to manage.

Such weaknesses are generally easy to detect through a careful evaluation of access privileges, but that can be a challenge due to the sheer number of users and privileges within applications.

Business impacts

When attackers have unfettered access to API functionality, the business impacts can be severe. It can lead to exposure of sensitive data, corruption or loss of data, or service disruption. For example, attackers may be able to access user accounts, create or delete accounts or data, take over accounts, or escalate privileges.

How broken function level authorization works

Authorization at the function level provides granular control of specific functions within an application. Without appropriate access controls at the function level, data may be exposed. This can happen in several ways, such as:

• Incorrect settings within role-based access control (RBAC)
• Coding errors, incorrect configurations, or lack of authorization checks for functions
• Overly predictable patterns, such as sequential IDs or patterns that are easy to guess
• Exposure of implementation or configuration details, such as database keys or IDs

Most commonly, these exploits occur because API endpoints are set to authenticate users upon connection, but once a session has been established, endpoints do not check to ensure that users have the authorization to execute certain commands.

Real-world examples

Two specific real-world examples of BFLA exploits from 2022 show how potentially damaging this can be.

Personal information of Texas residents from nearly two million insurance claims was exposed. The API in the Texas Department of Insurance (DPI) allowed access to app functions that should have been protected. The flaw went unnoticed for nearly three years and was discovered during a data management audit.

Nearly 10 million customer records were compromised in a broken function level authorization exploit of Optus, the second-largest telecommunications company in Australia, in late 2022. Data was exfiltrated and the company was hit with ransom demands to prevent exposure.

Detecting broken function level authorization vulnerabilities

There are several approaches to detecting broken function level authorization vulnerabilities, including manual code reviews focusing on API access controls. Other methods include:

• Penetration testing, using manual or automated pen tests to similar real-world attacks to probe function-level vulnerabilities
• Fuzz testing, which includes testing API endpoints using unexpected or invalid inputs, or unauthorized users
• Reviewing user roles and privileges at the function level

Preventing broken function level authorization vulnerabilities

Stopping BFLA requires deploying appropriate authorization checks. For example, can a regular user access an administrative endpoint?

Specific strategies include:

Function-level validation

Users should have to clear authorization checks for each function and not just at the application level. Each operation should require authorization, preventing unauthorized users from accessing API functions.

Zero Trust Network Access (ZTNA)

Throughout the infrastructure, organizations should employ zero-trust practices. Even authorized users must be validated for each action so that even if users have passed through perimeter security, they must still be authorized at the function level.

Zero trust also incorporates the principle of least privilege (PoLP) to grant users the minimum level of access and privileges they need to complete authorized functions.

Secure session management

The use of secure session tokens, expiration time limits, and token revocation upon logout can also help limit unauthorized access to API functions.

Continuous monitoring

By comparing baseline activity against current activity, monitoring can scan for anomalies that may indicate suspicious activity and block access or flag for review. For example, rapid-fire API calls for sequential IDs may trigger warnings.

Manage all administrative access

All admin controllers should have separate authorization checks based on the user’s group and role. It is also important to segregate administrative privileges from general API functions, preventing access at the admin level without proper authorization.

Regular security audits

As with other potential API exploits, regular security audits and testing can help ensure strong security and access controls are in place to prevent unauthorized access to API endpoints and functionality.