Common Weakness Enumeration
A community-developed list of software and hardware weakness types that serve as a common language for describing security vulnerabilities
Different perspectives for understanding weaknesses
Groups of related weaknesses
Documented software and hardware flaws
Featured Views
Different perspectives for understanding and organizing weaknesses
This view is intended to facilitate research into weaknesses, including their inter-dependencies, and can be leveraged to systematically identify theoretical gaps within CWE. It is mainly organized according to abstractions of behaviors instead of how they can be detected, where they appear in code, or when they are introduced in the development life cycle. By design, this view is expected to include every weakness within CWE.
This view organizes weaknesses around concepts that are frequently used or encountered in hardware design. Accordingly, this view can align closely with the perspectives of designers, manufacturers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.
This view organizes weaknesses around concepts that are frequently used or encountered in software development. This includes all aspects of the software development lifecycle including both architecture and implementation. Accordingly, this view can align closely with the perspectives of architects, developers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.
Featured Categories
Groupings of related weaknesses for easier navigation
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that exist when an application does not properly validate or represent input. According to the authors of the Seven Pernicious Kingdoms, "Input validation and representation problems are caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input."
Weaknesses in this category are related to coding practices that are deemed unsafe and increase the chances that an exploitable vulnerability will be present in the application. These weaknesses do not directly introduce a vulnerability, but indicate that the product has not been carefully developed or maintained. If a program is complex, difficult to maintain, not portable, or shows evidence of neglect, then there is a higher likelihood that weaknesses are buried in the code.
Weaknesses in this category are related to the design and architecture of audit-based components of the system. Frequently these deal with logging user activities in order to identify attackers and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is indeed who it claims to be. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have the required permissions before performing certain operations, such as modifying data. The weaknesses in this category could lead to a degradation of quality of the authorization capability if they are not addressed when designing or implementing a secure architecture.
Featured Weaknesses
Common software and hardware security weaknesses
This vulnerability occurs in a Struts application when a validator form either completely omits a validate() method or includes one but fails to call super.validate() within it.
This vulnerability occurs when software uses automated tools to optimize code for performance or efficiency, but those optimizations accidentally weaken or bypass critical security protections that the original code relied upon.
This vulnerability occurs in Apache Struts applications when a form bean class does not properly extend the framework's validation class. This bypasses the built-in Validator framework, leaving the application without structured input validation and open to various injection and data manipulation attacks.
This vulnerability occurs when a Struts application form contains an input field that lacks a corresponding validator, leaving it open to unverified user input.
This weakness occurs when a Java application, particularly one using the Struts framework, does not implement a structured input validation plugin like the Struts Validator. Skipping this framework forces developers to write custom validation logic, which is often error-prone and increases the risk of security flaws from improperly handled user input.
About CWE
The Common Weakness Enumeration (CWE) is a community-developed list of common software and hardware security weaknesses. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.
CWE is maintained by the MITRE Corporation and is sponsored by the Cybersecurity and Infrastructure Security Agency (CISA) and the National Cyber Security Division (NCSD) of the U.S. Department of Homeland Security (DHS).