Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')

Draft Class
Structure: Simple
Description

This weakness occurs when a security feature is implemented with excessive complexity, creating unnecessary risk. Overly intricate protection mechanisms are harder to understand, configure, and implement correctly, often leading to security gaps and misconfigurations.

Extended Description

Security controls should follow the principle of 'economy of mechanism'—the simpler they are, the more reliable they become. Complex designs increase the chance of implementation errors, compatibility issues, and mismatches between the intended security model and its real-world deployment. Developers are more likely to correctly implement, test, and maintain straightforward solutions. This principle also applies to data structures and validation logic. Overly complex data specifications force you to write equally complex validation code, which is prone to bugs. Whenever possible, favor simple system architectures and data models, as they naturally require simpler and more robust security checks.

Common Consequences 1
Scope: Other

Impact: Other

Potential Mitigations 1
Phase: Architecture and Design
Avoid complex security mechanisms when simpler ones would meet requirements. Avoid complex data models, and unnecessarily complex operations. Adopt architectures that provide guarantees, simplify understanding through elegance and abstraction, and that can be implemented similarly. Modularize, isolate and do not trust complex code, and apply other secure programming principles on these modules (e.g., least privilege) to mitigate vulnerabilities.
Demonstrative Examples 2

ID : DX-165

The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.
HTTP Request Smuggling (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')) attacks are feasible because there are not stringent requirements for how illegal or inconsistent HTTP headers should be handled. This can lead to inconsistent implementations in which a proxy or firewall interprets the same data stream as a different set of requests than the end points in that stream.
Observed Examples 4
CVE-2007-6067Support for complex regular expressions leads to a resultant algorithmic complexity weakness (Inefficient Algorithmic Complexity).
CVE-2007-1552Either a filename extension and a Content-Type header could be used to infer the file type, but the developer only checks the Content-Type, enabling unrestricted file upload (Unrestricted Upload of File with Dangerous Type).
CVE-2007-6479In Apache environments, a "filename.php.gif" can be redirected to the PHP interpreter instead of being sent as an image/gif directly to the user. Not knowing this, the developer only checks the last extension of a submitted filename, enabling arbitrary code execution.
CVE-2005-2148The developer cleanses the $_REQUEST superglobal array, but PHP also populates $_GET, allowing attackers to bypass the protection mechanism and conduct SQL injection attacks against code that uses $_GET.
References 2
The Protection of Information in Computer Systems
Jerome H. Saltzer and Michael D. Schroeder
Proceedings of the IEEE 63
09-1975
ID: REF-196
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Operation
Alternate Terms

Unnecessary Complexity