Allowlist-Preferred Input Validation (Deny-by-Default Filtering)
Description
Structure all security-sensitive input validation as allowlists (explicit permit lists with default-deny) rather than denylists (explicit block lists with default-permit). Denylists are inherently incomplete — every new input format, encoding variant, or aliasing technique the denylist does not cover becomes a bypass vector. Allowlists reject unknown or unexpected inputs by default, requiring the attacker to find an input that both matches the allowlist pattern and achieves the malicious objective. When allowlists are impractical (e.g., HTML sanitization where the set of safe elements is large but finite), combine a denylist with input canonicalization (CME-1314) and output encoding to create defense in depth. This control applies to SSRF destination validation, deserialization type validation, sandbox capability restrictions, application security policies, and any context where a list determines whether an input is permitted. For data written to resources that an interpreter might execute, such as templates, include files, interpreter configuration, libraries, or generated code, allowlist the complete permitted data grammar and reject directives or executable syntax. Store untrusted data outside executable resources whenever possible; when it must be written to an executable context, apply context-appropriate output encoding or neutralization before the write.
CVSS Vector Impacts
| Metric | Transition | Rationale |
|---|---|---|
| Attack Complexity (AC) | L → H | The attacker must find an input that satisfies the explicit allowlist criteria while still achieving the malicious objective — this is fundamentally harder than finding an input that evades a denylist, because novel or unexpected input formats are rejected by default rather than implicitly permitted |
| Integrity (I) | H → L | Unauthorized operations (SSRF to internal hosts, deserialization of gadget types, sandbox escape via unblocked APIs, policy-bypassed file access) are prevented because only explicitly permitted targets, types, capabilities, or destinations are accepted |
CWE Relationships
Verification
Review application source code and configuration to verify that security-sensitive input validation uses explicit allowlists with default-deny semantics rather than denylists with default-permit. Check SSRF filters, deserialization type validators, sandbox capability lists, application security policy files, and all write paths to templates, include files, interpreter configuration, libraries, or generated code. Verify that untrusted data is rejected unless it matches the complete permitted grammar and that it cannot introduce executable directives.
# Expected: Security validation uses allowlist patterns (explicit permit with default deny)
# Expected: Denylist patterns should be supplementary to allowlists, not the sole validation mechanism