How to remediate – OpenAPI Missing MIME Types

1. Introduction

OpenAPI Missing MIME Types refers to a lack of defined `consumes` and `produces` fields within an OpenAPI specification file. This means the API may accept any data type for requests, and return any data type in responses, potentially leading to server-side vulnerabilities like SQL injection or XXE attacks, as well as client-side issues such as XSS. REST APIs using version 2 of the OpenAPI specification are commonly affected. A successful exploit could compromise confidentiality, integrity, and availability of the API and underlying systems.

2. Technical Explanation

The root cause is an incomplete or incorrectly configured OpenAPI definition file. The `consumes` field specifies accepted request data types (e.g., application/json), while `produces` defines response formats. When these fields are absent, the API implementation might not validate input and output data correctly. An attacker could send a malicious payload in an unexpected format that bypasses intended security checks.

• Root cause: Missing `consumes` or `produces` fields in OpenAPI version 2 specification.
• Exploit mechanism: An attacker sends a request with a non-expected MIME type containing a malicious payload (e.g., an XML document crafted to trigger XXE). The API processes this data without validation, leading to potential code execution or data leakage.
• Scope: REST APIs using OpenAPI version 2 definitions are affected.

3. Detection and Assessment

Confirm vulnerability by inspecting the OpenAPI definition file for missing `consumes` and `produces` fields. A thorough method involves parsing the YAML or JSON file.

• Quick checks: Use a text editor to open the OpenAPI definition file and search for the keywords “consumes” and “produces”.
• Scanning: API security scanners may identify missing MIME types as part of their standard vulnerability assessments.
• Logs and evidence: Review API gateway logs or application logs for unexpected content types being processed.

grep -r "consumes" /path/to/openapi-definition.yaml

4. Solution / Remediation Steps

Specify the `consumes` and `produces` fields with supported MIME types in the OpenAPI description file according to the specification, and ensure API implementation enforces these definitions.

4.1 Preparation

• Ensure that all API implementations adhere to the updated specification. A roll back plan involves restoring the original backup of the OpenAPI definition file.
• Change windows may be required depending on service impact and approval processes.

4.2 Implementation

1. Step 1: Open the OpenAPI definition file (YAML or JSON) in a text editor.
2. Step 2: Add the `consumes` field to the appropriate section of the API definition, listing supported MIME types (e.g., `consumes: [application/json]`).
3. Step 3: Add the `produces` field to the appropriate section, listing supported response MIME types (e.g., `produces: [application/json]`).
4. Step 4: Save the modified OpenAPI definition file.
5. Step 5: Redeploy the API with the updated specification.

4.3 Config or Code Example

Before

paths:
  /example:
    post:
      summary: Example endpoint
      parameters: []

After

paths:
  /example:
    post:
      summary: Example endpoint
      consumes: [application/json]
      produces: [application/json]
      parameters: []

4.4 Security Practices Relevant to This Vulnerability

• Input validation: Validate all incoming data against expected formats and types, even if the OpenAPI specification is correct.
• Safe defaults: Use restrictive default settings for API configurations, minimizing potential attack surfaces.

4.5 Automation (Optional)

No suitable automation script provided as it depends on deployment tools.

5. Verification / Validation

Confirm the fix by inspecting the updated OpenAPI definition file and verifying that `consumes` and `produces` fields are present with correct values. Test API functionality to ensure compatibility.

• Post-fix check: Use a text editor to open the modified OpenAPI definition file and confirm the presence of both `consumes` and `produces` fields, listing expected MIME types.
• Re-test: Re-run the earlier detection method (grep) to ensure no missing fields are present.
• Smoke test: Send a valid request with an accepted content type and verify the API returns a successful response in the expected format.
• Monitoring: Monitor API logs for unexpected content types being processed, indicating potential bypass attempts.

grep -r "consumes" /path/to/updated-openapi-definition.yaml

6. Preventive Measures and Monitoring

• Baselines: Incorporate OpenAPI validation checks into security baselines or policies, ensuring all API definitions adhere to best practices.
• Pipelines: Implement SAST tools in CI pipelines to automatically scan for missing MIME types and other specification errors during development.
• Asset and patch process: Review API specifications as part of regular asset management and configuration review cycles.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the original backup of the OpenAPI definition file. Redeploy the API using the previous configuration.

8. References and Resources

• Vendor advisory or bulletin: Not applicable in this case, as it is a general specification issue.
• NVD or CVE entry: No specific CVE exists for missing MIME types; however, related vulnerabilities like XXE injection may be relevant.
• Product or platform documentation relevant to the fix: https://swagger.io/docs/specification/2-0/mime-types/