Permissive List of Allowed Inputs

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application's security filter uses an allowlist that is too broad, mistakenly permitting dangerous inputs that should have been blocked. The flawed assumption that everything on the list is safe creates a direct path for attackers to exploit the system.

Extended Description

An overly permissive allowlist is like a faulty bouncer at a club's door—it lets in troublemakers because the guest list isn't specific enough. Developers often create these lists to validate data like filenames, URLs, or user roles, but if the criteria are vague (e.g., allowing all files with a '.pdf' extension without checking the actual content), attackers can slip malicious payloads through. This bypasses the primary defense, leading to issues like command injection, path traversal, or cross-site scripting. Preventing this requires strict, context-aware validation rules that go beyond simple pattern matching. You must understand the exact, legitimate data your feature needs and deny everything else by default. Managing this at scale across hundreds of APIs and filters is difficult; an ASPM like Plexicus can help you track and remediate these flawed allowlist policies across your entire application stack, ensuring your validation logic is consistently robust.

Common Consequences 1
Scope: Access Control

Impact: Bypass Protection Mechanism

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Observed Examples 5
CVE-2019-12799chain: bypass of untrusted deserialization issue (Deserialization of Untrusted Data) by using an assumed-trusted class (Permissive List of Allowed Inputs)
CVE-2019-10458sandbox bypass using a method that is on an allowlist
CVE-2017-1000095sandbox bypass using unsafe methods that are on an allowlist
CVE-2019-10458CI/CD pipeline feature has unsafe elements in allowlist, allowing bypass of script restrictions
CVE-2017-1000095Default allowlist includes unsafe methods, allowing bypass of sandbox
References 1
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Alternate Terms

Allowlist / Allow List

This is used by CWE and CAPEC instead of other commonly-used terms. Its counterpart is denylist.

Safelist / Safe List

This is often used by security tools such as firewalls, email or web gateways, proxies, etc.

Whitelist / White List

This term is frequently used, but usage has been declining as organizations have started to adopt other terms.
Taxonomy Mapping
  • PLOVER