CWE-20: Improper Input Validation

Input validation applies to raw data and metadata, including strings, numbers, parameters, file contents, headers, and sizes. Validation may need to establish size and range limits, indexes and offsets, symbolic keys, syntax and lexical correctness, data type, consistency between related values, conformance to business rules, equivalence, and authenticity or ownership claims.

The data may be simple or deeply structured, with nested combinations of metadata and raw values. Properties that are implied or derived by the application must also be calculated correctly. Validation failures can occur when developers trust client-side checks, cookies, hidden fields, or other inputs that an attacker can modify, or when validation is incomplete, occurs before data from multiple sources is combined, or is bypassed through decoding and representation differences.

This weakness is a broad validation failure rather than a problem limited to one input format. It can affect network data, request parameters and headers, cookies, environment variables, reverse DNS results, URL components, email, files and filenames, databases, API results, and data supplied by external systems. The failure may involve missing values, extra values, malformed syntax, invalid types, out-of-range quantities, inconsistent length or size fields, unsafe references, or violations of domain-specific rules.

It is commonly introduced during architecture and design when trust boundaries are misunderstood, and during implementation when checks are omitted or applied inconsistently. It is especially important at component interfaces, language boundaries, and transitions between external representations and internal data.

Depending on the input and the affected component, an attacker may cause crashes, restarts, excessive CPU or memory consumption, or other denial of service. Control over resource references may expose memory, files, or directories. Malicious input may also modify memory or data, alter control flow, or result in unauthorized code or command execution.

Architecture and design:

• Reduce the attack surface by identifying every path through which untrusted data can enter, including indirect inputs obtained through API calls.
• Consider language-theoretic security techniques. Use a formal input language and a distinct parsing and recognition layer that separates raw input from internal representations.
• Use established validation libraries or frameworks such as Struts or the OWASP ESAPI Validation API, while reviewing their use because a framework does not eliminate validation errors.
• Duplicate security checks on the server when checks also run on the client. Client-side checks remain useful for feedback, intrusion indicators, and reducing accidental errors, but cannot protect the server by themselves.

Implementation:

• Assume all input may be malicious and prefer an allowlist, or “accept known good,” strategy. Check length, type, full value ranges, missing and extra fields, syntax, cross-field consistency, and business rules. Denylists may supplement detection or rejection of obviously malformed input, but should not be the sole defense.
• Validate data after combining values from multiple sources, because individually valid elements may violate restrictions when combined.
• Validate carefully across language boundaries, including calls from interpreted code to native code.
• Convert input directly to the expected type, then check its permitted range and consistency with related fields.
• Decode and canonicalize input into the application's internal representation before validation, avoid unintended repeated decoding, and use canonicalization controls such as the OWASP ESAPI Canonicalization control.
• Use the same character encoding between communicating components and explicitly set the encoding where the protocol permits it.

Use multiple complementary approaches because no single method covers all validation rules. Automated static analysis can identify locations where recognized validation methods or frameworks are absent, but may produce false positives when custom validation is not understood. Manual static analysis is necessary for custom rules, especially business logic.

Fuzzing should supply unexpected inputs and verify that the application remains stable and returns application-controlled errors rather than crashes, exceptions, or interpreter-generated messages. The record also identifies binary or bytecode disassembly and weakness analysis, web, web-service, and database scanners, fuzz testers and framework-based fuzzers, host interface scanning, monitored virtual environments, focused source spot checks, manual source review, source-code weakness analyzers, inspections, formal methods, and attack modeling. The SOAR-listed binary, bytecode, and partial-coverage methods are not complete coverage guarantees.

The official record provides the following representative examples, not an exhaustive list. They include:

• CVE-2024-37032: an unvalidated digest format enabled relative path traversal in an LLM management tool.
• CVE-2022-45918: an improperly validated path enabled traversal using ../ sequences.
• CVE-2021-30860 and CVE-2021-30663: improper validation led to integer overflow.
• CVE-2021-22205: validation bypass through a backslash followed by a newline led to eval injection.
• CVE-2021-21220: insufficient validation led to heap corruption.
• CVE-2020-9054, CVE-2008-5305, and CVE-2008-1625: insufficient validation enabled command or eval injection and code execution.
• CVE-2020-3452, CVE-2008-1284, and CVE-2008-3660: validation failures contributed to directory traversal.
• CVE-2020-3580, CVE-2008-3843, and CVE-2008-2223: validation failures contributed to XSS or SQL injection.
• Other listed examples involve malformed or inconsistent packet fields, missing parameters, zero-length values, invalid versions, infinite loops, crashes, information exposure, memory over-read or corruption, resource consumption, HTTP response smuggling, security bypass, and code execution.