Mitigating OWASP API Security Risk: Security Misconfiguration using F5 BIG-IP

Introduction

In the age of digital transformation, APIs have become the backbone of many modern applications. They allow different systems to communicate with each other, exchange data, and perform critical tasks. However, with great power comes great responsibility. Improperly configuring these APIs can leave them vulnerable to security risks, potentially exposing sensitive data or allowing malicious actors to exploit weaknesses. One of the most common and dangerous risks is security misconfiguration—a vulnerability that occurs when an API or its environment is not properly configured, leaving it exposed to threats.

This article explores the concept of security misconfiguration, with a focus on an example of CORS (Cross-Origin Resource Sharing) misconfiguration, which is one of the most common pitfalls in API security. We’ll explore how misconfigurations like these can be harmful and how to avoid them using F5 advanced WAF.

What is Security Misconfiguration?

Security misconfiguration happens when security settings or configurations are incorrect, incomplete, or missing. This can be due to a variety of reasons, such as:

Leaving default settings in place: Many web servers, application frameworks, or APIs come with default configurations. If these settings are not changed or secured before deployment, attackers may exploit them.
Exposed sensitive data: Misconfigured APIs might unintentionally expose sensitive information, such as internal API endpoints, database credentials, or user data.
Improper permissions: APIs might be too permissive, allowing unauthorized users to access restricted data or perform administrative actions.
Unpatched vulnerabilities: Failing to regularly update APIs and their underlying components can leave known vulnerabilities unaddressed, which can be exploited by attackers.
Excessive error messages: Overly detailed error messages, often left in production environments, can leak valuable information about the API’s structure, technologies, or data.

Example: CORS Misconfiguration

Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers to restrict how resources on a web server can be requested from another domain. By default, web browsers block cross-origin requests, meaning a script running on one domain cannot make requests to a different domain unless the server explicitly allows it.

Preflight Requests

A preflight request is a special type of HTTP OPTIONS request sent by the browser as part of the Cross-Origin Resource Sharing (CORS) protocol. It checks if the server permits the actual request with specific HTTP methods (e.g., PUT, DELETE) or custom headers. The browser sends this request automatically before executing certain cross-origin requests that do not qualify as "simple requests." Server responds with headers like Access-Control-Allow-Methods and Access-Control-Allow-Origin to indicate permission. This ensures secure cross-origin communication between client and server.

How CORS Misconfiguration Works

For example, an API might be designed to allow cross-origin requests from legitimate web applications. To do this, the server sends an Access-Control-Allow-Origin header in the HTTP response to specify which domains are allowed to access its resources. A misconfigured CORS setting might look like this: Access-Control-Allow-Origin: *

The * wildcard means the API allows requests from any domain. While this may seem convenient for open APIs, it presents a serious security issue. Any malicious website could make unauthorized requests to the API on behalf of the user, potentially compromising their data and the integrity of the system.

Imagine a user is logged into an online banking application. If the bank’s API has a misconfigured CORS policy, an attacker could create a malicious website that sends a request to the bank's API. If the user visits this site while logged in, the malicious website could make requests on behalf of the user, such as transferring funds or retrieving sensitive account information, without the user's consent.

This is possible because the API has no restrictions on the domains allowed to send requests, thus enabling cross-origin attacks like Cross-Site Request Forgery (CSRF).

Attack Demonstration:

For this demonstration, we will see how we can exploit the CORS Misconfiguration in ‘OWASP Juice Shop’ application. This application is added as a pool member to BIG-IP and can be accessed via a virtual server. For more information, refer to how to add pool member .

If we take a closer look at the login endpoint of the juice shop application, “Access-Control-Allow-Origin” header is set to * which means access from all origins is allowed.

From a malicious application I am making a cross-origin request to the login endpoint and due to CORS misconfiguration, I can retrieve the auth token as shown below.

Mitigation using Advanced WAF:

Navigate to Security > Application Security > Security Policies > and create an application policy with below configurations.

Enforcement mode: Blocking

Signature Staging: Enabled

Policy Building Learning Mode: Automatic

Virtual Sever: < Virtual server on which juice shop application is accessible>

Other configs are set to default values

Note: Staging is enabled by default while creating the application security policy and the default staging period is 7 days. It can be tuned according to the customer’s requirements. For more information related to staging, refer to Attack Signatures & Staging.

Navigate to Security >> Application Security >> Headers >> Methods and create new “OPTIONS” method to allow Preflight requests.

Navigate to Security >> Application Security >> URLs >> Allowed HTTP URLs and click on [HTTP] * URL.

Navigate to Advanced Allowed URL properties > HTML5 Cross-Domain Request Enforcement and select Enforcement mode as “Replace CORS Headers” and add the IP or domain name of the respective origins from where we want to allow the cross-domain request in Allowed origins section.

Also, we can add methods which we want to allow under the Allowed Methods section.

Now that we have a CORS policy enforced to allow requests only from the origins that we added in Advanced WAF, lets try to regenerate a cross-domain request attack to the login endpoint.

From the above screenshot it is evident that the request is blocked by the CORS policy since the malicious application is not part of Allowed Origins.

Conclusion:

Security misconfigurations remain one of the most common and impactful threats to API security. Despite being avoidable, they can lead to devastating consequences if not properly addressed. This article covers the basics of security misconfiguration, along with a demo of CORS misconfiguration use case as an example and how these types of misconfigurations can be effectively mitigated using F5 Advanced WAF.