API8—Security Misconfiguration

>Control Description

The API might be vulnerable if appropriate security hardening is missing across any part of the API stack, or if there are improperly configured permissions on cloud services. If the latest security patches are missing or the systems are out of date. If unnecessary features are enabled (e.g. HTTP verbs, logging features). If there are discrepancies in the way incoming requests are processed by servers in the HTTP server chain. If Transport Layer Security (TLS) is missing. If security or cache control directives are not sent to clients. If a Cross-Origin Resource Sharing (CORS) policy is missing or improperly set. If error messages include stack traces or expose other sensitive information.

>Prevention & Mitigation Strategies

1.The API life cycle should include a repeatable hardening process leading to fast and easy deployment of a properly locked down environment.
2.Have a task to review and update configurations across the entire API stack. The review should include: orchestration files, API components, and cloud services (e.g. S3 bucket permissions).
3.An automated process to continuously assess the effectiveness of the configuration and settings in all environments.
4.Ensure that all API communications from the client to the API server and any downstream/upstream components happen over an encrypted communication channel (TLS), regardless of whether it is an internal or public-facing API.
5.Be specific about which HTTP verbs each API can be accessed by: all other HTTP verbs should be disabled (e.g. HEAD).
6.Implement a proper Cross-Origin Resource Sharing (CORS) policy for APIs accessed from browser-based clients (e.g., WebApp front-end).
7.Include applicable Security Headers for APIs accessed from browser-based clients.
8.Restrict incoming content types/data formats to those that meet the business/functional requirements.
9.Ensure all servers in the HTTP server chain (e.g. load balancers, reverse and forward proxies, and back-end servers) process incoming requests in a uniform way to avoid desync issues.
10.Where applicable, define and enforce all API response payload schemas, including error responses, to prevent exception traces and other valuable information from being sent back to the attacker.

>Attack Scenarios

#1JNDI injection via logging utility

An API back-end server uses a popular third-party logging utility with JNDI (Java Naming and Directory Interface) lookups enabled by default. For each request, the logger writes a new log entry containing the request header value for X-Api-Version. An attacker sends a crafted request with X-Api-Version containing a JNDI lookup expression that the logger evaluates, causing Remote Code Execution (RCE) on the server.

#2Browser cache exposing private messages

An API serving a messaging application does not include the Cache-Control header in responses containing private direct messages. As a result, private messages are cached by the browser. A malicious user retrieves cached conversation data by reading browser cache files from the filesystem of a shared computer.

>Related CWEs

>References

Ask AI

Configure your API key to use AI features.