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.
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, and application security policy files.
# Expected: Security validation uses allowlist patterns (explicit permit with default deny)
# Expected: Denylist patterns should be supplementary to allowlists, not the sole validation mechanism