Skip to content

CWE-20: Improper Input Validation

Overview

Improper Input Validation occurs when an application fails to enforce required constraints on externally supplied data before it is used. While input validation alone does not prevent many classes of vulnerabilities, its absence often allows unexpected or malformed values to reach security-sensitive logic, enabling other failures.

Static analysis tools commonly flag CWE-20 when code accepts external input without clear type, range, format, or semantic constraints prior to use. This finding indicates a lack of defensive boundaries, not necessarily an immediately exploitable condition.

OWASP Classification

A05:2025 – Injection

Note: OWASP maps CWE-20 under Injection because unconstrained input frequently enables injection-style flaws when it reaches interpreters or security-sensitive operations.

Risk

Medium: Improper input validation rarely results in direct exploitation on its own. However, it frequently enables other vulnerabilities by allowing unexpected data to influence application behavior, control flow, or downstream components. Impact depends entirely on how and where the input is used.

CWE-20 commonly acts as a supporting failure or bypass primitive, rather than a standalone vulnerability.

What Static Analysis Identified

Static analysis findings for CWE-20 typically indicate that externally supplied data is:

  • Accepted without explicit type or format constraints
  • Passed through application logic without normalization or bounds enforcement
  • Used directly by downstream operations that assume well-formed input

These findings highlight missing defensive constraints, not proof of exploitability.

Mapping the Issue to Source Code

CWE-20 does not map to a single vulnerable endpoint or function. Instead, it reflects missing constraints at trust boundaries.

When reviewing source code, focus on:

  • Entry points where external input is first accepted
  • Assumptions made about input shape, type, or range
  • Implicit conversions or defaults applied to unvalidated data
  • Use of external input in security-sensitive decisions or operations

Validation gaps are most significant where input crosses from untrusted to trusted contexts.

Remediation Steps

Core Principle: CWE-20 is an abstract weakness - the correct fix depends on identifying the specific child CWE that matches how the unvalidated input is actually used, then applying the appropriate defense for that vulnerability.

CWE-20 findings indicate missing input constraints, but the remediation must address the specific security risk posed by that unconstrained input.

Trace the data flow to identify the specific vulnerability

Follow the unvalidated input from entry point to where it's used:

  • Where does the input originate? (HTTP parameter, header, file upload, API request, database query result)
  • Where is it used? (HTML output, SQL query, shell command, file path, LDAP query, XML parser, eval statement)
  • What security-sensitive operations does it influence? (authentication, authorization, file access, code execution)

Map to the specific child CWE

Identify which specific vulnerability applies based on the data flow:

Input Usage Context Specific CWE Primary Defense
HTML output (templates, responses) CWE-79: XSS Output encoding/escaping
SQL query (WHERE, ORDER BY, etc.) CWE-89: SQL Injection Parameterized queries
Shell command (system(), exec()) CWE-78: OS Command Injection Avoid shell execution, use APIs
File path (open(), include()) CWE-22: Path Traversal Allowlist validation, canonicalization
LDAP query CWE-90: LDAP Injection Parameterized LDAP queries
XML parser CWE-611: XXE Disable external entities
eval/exec (dynamic code) CWE-95: Code Injection Never use eval with user input
HTTP redirect CWE-601: Open Redirect Allowlist validation
SSRF targets CWE-918: SSRF URL validation, network restrictions
Deserialization CWE-502: Unsafe Deserialization Use safe serialization formats
Integer operations CWE-190: Integer Overflow Range validation, safe math

Apply the specific defense for that child CWE

  • Navigate to the specific CWE guidance file (linked in table above)
  • Apply the primary defense (parameterized queries, output encoding, etc.) - this is the actual fix
  • Do not rely on input validation alone - it's supplementary, not sufficient

After applying the primary defense, add validation as an additional layer:

  • Type validation: Ensure input matches expected data type (integer, email, UUID, etc.)
  • Format validation: Use regex or parsing to enforce structure (date format, phone number pattern)
  • Range validation: Check numeric bounds, string length limits, date ranges
  • Allowlist validation: Compare against known-good values (enum, predefined list)
  • Semantic validation: Verify business logic constraints (age > 0, future dates only)

Example:

// Primary defense: Parameterized query (prevents SQL injection)
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setInt(1, userId);  // Type-safe parameter binding

// Defense-in-depth: Input validation (rejects obviously invalid values)
if (userId < 1 || userId > Integer.MAX_VALUE) {
    throw new IllegalArgumentException("Invalid user ID");
}

Verify the fix addresses the root vulnerability

  • Confirm the specific child CWE is remediated (XSS prevented, SQL injection blocked, etc.)
  • Ensure input validation is supplementary, not the sole defense
  • Test with malicious payloads specific to the identified vulnerability type

Verification and Follow-Up

After addressing CWE-20 findings:

  • Confirm that required constraints are explicit and enforced at trust boundaries
  • Verify that security-sensitive logic does not depend solely on validation correctness
  • Review related CWEs where unconstrained input could have greater impact
  • Re-run static analysis to ensure missing constraints are no longer reported

Test Edge Cases

When reviewing fixes, consider:

  • Unexpected but syntactically valid values
  • Boundary conditions and default behaviors
  • Implicit type coercion or fallback logic
  • Alternate execution paths that bypass validation

Focus on design correctness, not exhaustive input filtering.

Additional Resources