1. Home
  2. Web App Vulnerabilities
  3. How to remediate – OpenAPI Permissive Input Validation

How to remediate – OpenAPI Permissive Input Validation

1. Introduction

OpenAPI Permissive Input Validation refers to weaknesses in how APIs handle data received through their OpenAPI definition files. These files describe API endpoints and expected inputs, but missing property definitions can allow malicious input formats. This could lead to Denial of Service (DoS) attacks or Remote Code Execution (RCE). Systems using REST APIs described by OpenAPI specifications are usually affected. A successful exploit may compromise confidentiality, integrity, and availability of the service.

2. Technical Explanation

The root cause is incomplete property declarations within an API’s OpenAPI definition file. When input data types lack defined properties, the backend implementation might not properly validate incoming requests. An attacker can exploit this by sending crafted payloads that bypass validation checks. The Common Weakness Enumeration (CWE) identifier for this issue is 20. For example, an attacker could send a request with unexpected data types or excessively large inputs to cause a crash or execute arbitrary code if the backend processes unvalidated data.

  • Root cause: Missing properties on objects specified in the OpenAPI definition file.
  • Exploit mechanism: Attackers submit requests containing malicious input formats that exploit the lack of validation due to incomplete definitions. An example payload could include a very large string where an integer was expected, causing a buffer overflow or resource exhaustion.
  • Scope: REST APIs using OpenAPI specifications (versions 3.0.2 and later are known to be affected).

3. Detection and Assessment

Confirming vulnerability requires reviewing the API’s OpenAPI definition file. A quick check involves verifying the file exists and is accessible. Thorough assessment means parsing the file for missing properties on data types.

  • Quick checks: Verify the existence of the OpenAPI specification file (usually YAML or JSON) in the API documentation directory.
  • Scanning: Static analysis tools designed to parse OpenAPI definitions can identify missing property declarations. Several commercial and open-source scanners are available, but results should be verified manually.
  • Logs and evidence: Examine API logs for unexpected errors related to input validation failures or unusual data processing behaviour. Look for exceptions caused by invalid data types.
cat /path/to/openapi.yaml | grep -c 'type:'

4. Solution / Remediation Steps

Fixing this issue involves ensuring all required properties are declared in the OpenAPI definition file and that the API backend enforces validation based on these definitions.

4.1 Preparation

  • Ensure you have access to modify the OpenAPI definition file and redeploy the API backend. A roll back plan involves restoring the backed-up OpenAPI file and restarting the affected service.
  • Change windows may be required depending on your deployment process; approval from relevant stakeholders might also be necessary.

4.2 Implementation

  1. Step 1: Review the OpenAPI definition file for any data types (objects or arrays) that lack property definitions.
  2. Step 2: Add missing properties to the corresponding schema objects in the YAML or JSON file, specifying their type and format.
  3. Step 3: Redeploy the API backend with the updated specification file.

4.3 Config or Code Example

Before

# Missing property definitions
components:
  schemas:
    User:
      type: object

After

# Added property definitions
components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: integer
          format: int64
        username:
          type: string
        email:
          type: string

4.4 Security Practices Relevant to This Vulnerability

Several security practices directly address this vulnerability type. Input validation is crucial for blocking unsafe data, while least privilege limits the impact if an exploit succeeds. Safe defaults reduce the risk of misconfiguration.

  • Practice 1: Input Validation – Validate all incoming data against a strict schema to prevent unexpected formats or values.
  • Practice 2: Least Privilege – Ensure API backend processes have only the necessary permissions to perform their tasks, limiting potential damage from successful exploits.

4.5 Automation (Optional)

If using infrastructure-as-code tools, you can automate OpenAPI definition validation as part of your CI/CD pipeline.

# Example Bash script to validate OpenAPI file against a schema
yamllint /path/to/openapi.yaml -strict # Requires yamllint installed

5. Verification / Validation

Confirm the fix by verifying that the updated OpenAPI definition includes all required properties and that the API backend enforces validation correctly.

  • Post-fix check: Run `cat /path/to/openapi.yaml | grep ‘properties:’` and confirm it returns expected property definitions for each schema object.
  • Re-test: Re-run the scanner used in detection to verify that no missing properties are reported.
  • Smoke test: Test key API endpoints with both valid and invalid inputs to ensure validation is working as expected.
  • Monitoring: Monitor API logs for input validation errors or unexpected exceptions, which could indicate a regression.
cat /path/to/openapi.yaml | grep 'properties:'

6. Preventive Measures and Monitoring

Update security baselines to include OpenAPI definition standards. Add checks in CI/CD pipelines to prevent incomplete definitions from being deployed. Implement a regular patch or configuration review cycle for API components.

  • Baselines: Update your security baseline to require complete property definitions in all OpenAPI specifications.
  • Asset and patch process: Review API configurations regularly (e.g., quarterly) to ensure compliance with security standards.

7. Risks, Side Effects, and Roll Back

Adding or modifying properties in the OpenAPI definition could potentially break existing clients if they rely on undocumented behaviour. A roll back involves restoring the backed-up OpenAPI file and restarting the affected service.

  • Roll back: Restore the backed-up OpenAPI specification file, restart the API backend service, and verify functionality.

8. References and Resources

Updated on December 27, 2025

Was this article helpful?

Related Articles