CWE - VIEW SLICE: CWE-1040: Quality Weaknesses with Indirect Security Impacts (4.10)

CWE VIEW: Quality Weaknesses with Indirect Security Impacts

View ID: 1040

Type: Implicit

Downloads: Booklet | CSV | XML

Objective

CWE identifiers in this view (slice) are quality issues that only indirectly make it easier to introduce a vulnerability and/or make the vulnerability more difficult to detect or mitigate.

Audience

Stakeholder	Description
Assessment Tool Vendors	This view makes it easier for assessment vendors to identify and improve coverage for quality-related weaknesses.
Software Developers	This view makes it easier for developers to identify and learn about issues that might make their code more difficult to maintain, perform efficiently or reliably, or secure.
Product Vendors	This view makes it easier for software vendors to identify important issues that may make their software more difficult to maintain, perform efficiently or reliably, or secure.

Filter

/Weakness_Catalog/Weaknesses/Weakness[Weakness_Ordinalities/Weakness_Ordinality/Ordinality='Indirect']

Membership

Nature	Type	ID	Name
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	474	Use of Function with Inconsistent Implementations
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	475	Undefined Behavior for Input to API
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	477	Use of Obsolete Function
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	483	Incorrect Block Delimitation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	484	Omitted Break Statement in Switch
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	489	Active Debug Code
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	546	Suspicious Comment
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	547	Use of Hard-coded, Security-relevant Constants
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	554	ASP.NET Misconfiguration: Not Using Input Validation Framework
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	561	Dead Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	562	Return of Stack Variable Address
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	563	Assignment to Variable without Use
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	585	Empty Synchronized Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	587	Assignment of a Fixed Address to a Pointer
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	589	Call to Non-ubiquitous API
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	594	J2EE Framework: Saving Unserializable Objects to Disk
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	676	Use of Potentially Dangerous Function
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	684	Incorrect Provision of Specified Functionality
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	766	Critical Data Element Declared Public
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1041	Use of Redundant Code
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1042	Static Member Data Element outside of a Singleton Class Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1043	Data Element Aggregating an Excessively Large Number of Non-Primitive Elements
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1044	Architecture with Number of Horizontal Layers Outside of Expected Range
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1045	Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1046	Creation of Immutable Text Using String Concatenation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1047	Modules with Circular Dependencies
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1048	Invokable Control Element with Large Number of Outward Calls
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1049	Excessive Data Query Operations in a Large Data Table
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1050	Excessive Platform Resource Consumption within a Loop
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1051	Initialization with Hard-Coded Network Resource Configuration Data
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1052	Excessive Use of Hard-Coded Literals in Initialization
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1053	Missing Documentation for Design
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1054	Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1055	Multiple Inheritance from Concrete Classes
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1056	Invokable Control Element with Variadic Parameters
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1057	Data Access Operations Outside of Expected Data Manager Component
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1058	Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1059	Insufficient Technical Documentation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1060	Excessive Number of Inefficient Server-Side Data Accesses
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1061	Insufficient Encapsulation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1062	Parent Class with References to Child Class
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1063	Creation of Class Instance within a Static Code Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1064	Invokable Control Element with Signature Containing an Excessive Number of Parameters
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1065	Runtime Resource Management Control Element in a Component Built to Run on Application Servers
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1066	Missing Serialization Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1067	Excessive Execution of Sequential Searches of Data Resource
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1068	Inconsistency Between Implementation and Documented Design
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1069	Empty Exception Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1070	Serializable Data Element Containing non-Serializable Item Elements
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1071	Empty Code Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1072	Data Resource Access without Use of Connection Pooling
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1073	Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1074	Class with Excessively Deep Inheritance
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1075	Unconditional Control Flow Transfer outside of Switch Block
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1076	Insufficient Adherence to Expected Conventions
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1077	Floating Point Comparison with Incorrect Operator
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1078	Inappropriate Source Code Style or Formatting
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1079	Parent Class without Virtual Destructor Method
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1080	Source Code File with Excessive Number of Lines of Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1082	Class Instance Self Destruction Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1083	Data Access from Outside Expected Data Manager Component
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1084	Invokable Control Element with Excessive File or Data Access Operations
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1085	Invokable Control Element with Excessive Volume of Commented-out Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1086	Class with Excessive Number of Child Classes
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1087	Class with Virtual Method without a Virtual Destructor
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1088	Synchronous Access of Remote Resource without Timeout
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1089	Large Data Table with Excessive Number of Indices
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1090	Method Containing Access of a Member Element from Another Class
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1091	Use of Object without Invoking Destructor Method
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1092	Use of Same Invokable Control Element in Multiple Architectural Layers
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1093	Excessively Complex Data Representation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1094	Excessive Index Range Scan for a Data Resource
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1095	Loop Condition Value Update within the Loop
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1096	Singleton Class Instance Creation without Proper Locking or Synchronization
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1097	Persistent Storable Data Element without Associated Comparison Control Element
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1098	Data Element containing Pointer Item without Proper Copy Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1099	Inconsistent Naming Conventions for Identifiers
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1100	Insufficient Isolation of System-Dependent Functions
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1101	Reliance on Runtime Component in Generated Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1102	Reliance on Machine-Dependent Data Representation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1103	Use of Platform-Dependent Third Party Components
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1104	Use of Unmaintained Third Party Components
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1105	Insufficient Encapsulation of Machine-Dependent Functionality
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1106	Insufficient Use of Symbolic Constants
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1107	Insufficient Isolation of Symbolic Constant Definitions
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1108	Excessive Reliance on Global Variables
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1109	Use of Same Variable for Multiple Purposes
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1110	Incomplete Design Documentation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1111	Incomplete I/O Documentation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1112	Incomplete Documentation of Program Execution
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1113	Inappropriate Comment Style
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1114	Inappropriate Whitespace Style
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1115	Source Code Element without Standard Prologue
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1116	Inaccurate Comments
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1117	Callable with Insufficient Behavioral Summary
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1118	Insufficient Documentation of Error Handling Techniques
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1119	Excessive Use of Unconditional Branching
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1120	Excessive Code Complexity
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1121	Excessive McCabe Cyclomatic Complexity
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1122	Excessive Halstead Complexity
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1123	Excessive Use of Self-Modifying Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1124	Excessively Deep Nesting
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1125	Excessive Attack Surface
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1126	Declaration of Variable with Unnecessarily Wide Scope
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1127	Compilation with Insufficient Warnings or Errors
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1164	Irrelevant Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1173	Improper Use of Validation Framework
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1174	ASP.NET Misconfiguration: Improper Model Validation
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1176	Inefficient CPU Computation
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1177	Use of Prohibited Code
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1357	Reliance on Insufficiently Trustworthy Component

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	112	out of	933
Categories	0	out of	352
Views	0	out of	47
Total	112	out of	1332

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-12	CWE Content Team	MITRE
2018-07-12	View originally constructed using entries from Common Quality Enumeration (CQE) Draft 0.9.
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated View_Audience

View Components

Weakness ID: 489

Abstraction: Base
Structure: Simple

View customized information:

Description

The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.

Extended Description

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the product.

Alternate Terms

Leftover debug code:	This term originates from Seven Pernicious Kingdoms

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	710	Improper Adherence to Coding Standards
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	11	ASP.NET Misconfiguration: Creating Debug Binary
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	215	Insertion of Sensitive Information Into Debugging Code

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation	In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, this oversight during the "software process" allows attackers access to debug functionality.
Build and Compilation
Operation

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Confidentiality Integrity Availability Access Control Other	Technical Impact: Bypass Protection Mechanism; Read Application Data; Gain Privileges or Assume Identity; Varies by Context The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.

Demonstrative Examples

Example 1

Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is:

(bad code)

Example Language: HTML

</FORM>

Then a conforming link will look like:

(informative)

http://TARGET/authenticate_login.cgi?username=...&password=...

An attacker can change this to:

(attack code)

http://TARGET/authenticate_login.cgi?username=&password=&debug=1

Which will grant the attacker access to the site, bypassing the authentication process.

Potential Mitigations

Phases: Build and Compilation; Distribution

Remove debug code before deploying the application.

Weakness Ordinalities

Ordinality	Description
Indirect	(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Primary	(where the weakness exists independent of other weaknesses)

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	485	7PK - Encapsulation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	731	OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1002	SFP Secondary Cluster: Unexpected Entry Points
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1371	ICS Supply Chain: Poorly Documented or Undocumented Features

Notes

Other

In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Leftover Debug Code
OWASP Top Ten 2004	A10	CWE More Specific	Insecure Configuration Management
Software Fault Patterns	SFP28		Unexpected access points

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-121	Exploit Non-Production Interfaces
CAPEC-661	Root/Jailbreak Detection Evasion via Debugging

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	7 Pernicious Kingdoms
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Description, Modes_of_Introduction, Other_Notes, Time_of_Introduction
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Relationships, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Description, Name, References, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Related_Attack_Patterns
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Alternate_Terms
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Description, Relationships
Previous Entry Names
Change Date	Previous Entry Name
2020-02-24	Leftover Debug Code

Weakness ID: 587

Abstraction: Base
Structure: Simple

View customized information:

Description

The product sets a pointer to a specific address other than NULL or 0.

Extended Description

Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	344	Use of Invariant Value in Dynamically Changing Context
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	465	Pointer Issues

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Execute Unauthorized Code or Commands If one executes code at a known location, an attacker might be able to inject code there beforehand.
Availability	Technical Impact: DoS: Crash, Exit, or Restart; Reduce Maintainability; Reduce Reliability If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.
Confidentiality Integrity	Technical Impact: Read Memory; Modify Memory The data at a known pointer location can be easily read or influenced by an attacker.

Demonstrative Examples

Example 1

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(bad code)

Example Language: C

int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.

Potential Mitigations

Phase: Implementation

Never set a pointer to a fixed address.

Weakness Ordinalities

Ordinality	Description
Indirect	(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	738	CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	872	CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1158	SEI CERT C Coding Standard - Guidelines 04. Integers (INT)

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	INT36-C	Imprecise	Converting a pointer to integer or integer to pointer
Software Fault Patterns	SFP1		Glitch in computation

Content History

Submissions
Submission Date	Submitter	Organization
2006-12-15	CWE Content Team	MITRE
2006-12-15
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Common_Consequences, Description, Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Common_Consequences, Weakness_Ordinalities
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description

Weakness ID: 766

Abstraction: Variant
Structure: Simple

View customized information:

Description

The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

Extended Description

This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1061	Insufficient Encapsulation

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	275	Permission Issues

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

Languages

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality	Technical Impact: Read Application Data; Modify Application Data Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.
Other	Technical Impact: Reduce Maintainability

Demonstrative Examples

Example 1

The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.

(bad code)

Example Language: C++

public: char* password;

Instead, the critical data should be declared private.

(good code)

Example Language: C++

private: char* password;

Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (CWE-257).

Example 2

The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.

(bad code)

Example Language: C++

#define MAX_PASSWORD_LENGTH 15
#define MAX_USERNAME_LENGTH 15

class UserAccount
{

public:

UserAccount(char *username, char *password)
{

if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {

ExitError("Invalid username or password");

}
strcpy(this->username, username);
strcpy(this->password, password);

}

int authorizeAccess(char *username, char *password)
{

if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {

ExitError("Invalid username or password");

}
// if the username and password in the input parameters are equal to

// the username and password of this account class then authorize access
if (strcmp(this->username, username) ||
strcmp(this->password, password))

return 0;

// otherwise do not authorize access
else

return 1;

}

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};

However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.

(good code)

Example Language: C++

class UserAccount
{
public:

...

private:

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};

Observed Examples

Reference	Description
CVE-2010-3860	variables declared public allows remote read of system properties such as user name and home directory.

Potential Mitigations

Phase: Implementation

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)
Indirect	(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	849	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1002	SFP Secondary Cluster: Unexpected Entry Points
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1130	CISQ Quality Measures (2016) - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1139	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
CLASP		Failure to protect stored data from modification
The CERT Oracle Secure Coding Standard for Java (2011)	OBJ01-J	Declare data members as private and provide accessible wrapper methods
Software Fault Patterns	SFP28	Unexpected access points
OMG ASCMM	ASCMM-MNT-15

References

[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-15. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.

Content History

Submissions
Submission Date	Submitter	Organization
2009-03-03	CWE Content Team	MITRE
2009-03-03
Modifications
Modification Date	Modifier	Organization
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Demonstrative_Examples
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Observed_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Common_Consequences, Description, Name, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
Previous Entry Names
Change Date	Previous Entry Name
2019-01-03	Critical Variable Declared Public

Weakness ID: 561

Abstraction: Base
Structure: Simple

View customized information:

Description

The product contains dead code, which can never be executed.

Extended Description

Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1164	Irrelevant Code
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	570	Expression is Always False
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	571	Expression is Always True

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.
Other	Technical Impact: Reduce Maintainability

Demonstrative Examples

Example 1

The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null, while on the only path where s can be assigned a non-null value there is a return statement.

(bad code)

Example Language: C++

String s = null;
if (b) {

s = "Yes";
return;

}

if (s != null) {

Dead();

}

Example 2

In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code.

(bad code)

Example Language: Java

public class DoubleDead {

private void doTweedledee() {

doTweedledumb();

}
private void doTweedledumb() {

doTweedledee();

}
public static void main(String[] args) {

System.out.println("running DoubleDead");

}

(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)

Example 3

The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant.

(bad code)

Example Language: Java

public class Dead {

String glue;

public String getGlue() {

return "glue";

}

Observed Examples

Reference	Description
CVE-2014-1266	chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).

Potential Mitigations

Phase: Implementation

Remove dead code before deploying the application.

Phase: Testing

Use a static analysis tool to spot dead code.

Weakness Ordinalities

Ordinality	Description
Indirect	(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)

Detection Methods

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Binary / Bytecode Quality Analysis

Compare binary / bytecode to application permission manifest

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Automated Monitored Execution

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Permission Manifest Analysis

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Source Code Quality Analyzer

Cost effective for partial coverage:

Warning Flags

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner

Web Services Scanner

Database Scanners

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	747	CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	883	CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	886	SFP Primary Cluster: Unused entities
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1130	CISQ Quality Measures (2016) - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1186	SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1307	CISQ Quality Measures - Maintainability

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	MSC07-C		Detect and remove dead code
SEI CERT Perl Coding Standard	MSC00-PL	Exact	Detect and remove dead code
Software Fault Patterns	SFP2		Unused Entities
OMG ASCMM	ASCMM-MNT-20

References

[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-20. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	Anonymous Tool Vendor (under NDA)
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Observed_Examples
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Common_Consequences, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description

Weakness ID: 1173

Abstraction: Base
Structure: Simple

View customized information:

Description

The product does not use, or incorrectly uses, an input validation framework that is provided by the source language or an independent library.

Extended Description

Many modern coding languages provide developers with input validation frameworks to make the task of input validation easier and less error-prone. These frameworks will automatically check all input against specified criteria and direct execution to error handlers when invalid input is received. The improper use (i.e., an incorrect implementation or missing altogether) of these frameworks is not directly exploitable, but can lead to an exploitable condition if proper input validation is not performed later in the product. Not using provided input validation frameworks can also hurt the maintainability of code as future developers may not recognize the downstream input validation being used in the place of the validation framework.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	20	Improper Input Validation
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	102	Struts: Duplicate Validation Forms
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	105	Struts: Form Field Without Validator
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	106	Struts: Plug-in Framework not in Use
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	108	Struts: Unvalidated Action Form
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	109	Struts: Validator Turned Off
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	554	ASP.NET Misconfiguration: Not Using Input Validation Framework
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1174	ASP.NET Misconfiguration: Improper Model Validation

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1215	Data Validation Issues

Modes Of Introduction

Phase	Note
Architecture and Design	This weakness may occur when software designers choose to not leverage input validation frameworks provided by the source language.
Implementation	This weakness may occur when developers do not correctly use a provided input validation framework.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity	Technical Impact: Unexpected State Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.

Potential Mitigations

Phase: Implementation

Properly use provided input validation frameworks.

Weakness Ordinalities

Ordinality	Description
Indirect	(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)

Detection Methods

Automated Static Analysis

Some instances of improper input validation can be detected using automated static analysis.

A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present.

Except in the cases described in the previous paragraph, automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design

Content History

Submissions
Submission Date	Submitter	Organization
2018-12-21	CWE Content Team	MITRE
2018-12-21
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description

Common Weakness Enumeration

CWE VIEW: Quality Weaknesses with Indirect Security Impacts

View Components

CWE-489: Active Debug Code

CWE-1044: Architecture with Number of Horizontal Layers Outside of Expected Range

CWE-1174: ASP.NET Misconfiguration: Improper Model Validation

CWE-554: ASP.NET Misconfiguration: Not Using Input Validation Framework

CWE-587: Assignment of a Fixed Address to a Pointer

CWE-563: Assignment to Variable without Use

CWE-589: Call to Non-ubiquitous API

CWE-1117: Callable with Insufficient Behavioral Summary

CWE-1082: Class Instance Self Destruction Control Element

CWE-1086: Class with Excessive Number of Child Classes

CWE-1074: Class with Excessively Deep Inheritance

CWE-1087: Class with Virtual Method without a Virtual Destructor

CWE-1127: Compilation with Insufficient Warnings or Errors

CWE-1063: Creation of Class Instance within a Static Code Block

CWE-1046: Creation of Immutable Text Using String Concatenation

CWE-766: Critical Data Element Declared Public

CWE-1083: Data Access from Outside Expected Data Manager Component

CWE-1057: Data Access Operations Outside of Expected Data Manager Component

CWE-1043: Data Element Aggregating an Excessively Large Number of Non-Primitive Elements

CWE-1098: Data Element containing Pointer Item without Proper Copy Control Element

CWE-1072: Data Resource Access without Use of Connection Pooling

CWE-561: Dead Code

CWE-1126: Declaration of Variable with Unnecessarily Wide Scope

CWE-1071: Empty Code Block

CWE-1069: Empty Exception Block

CWE-585: Empty Synchronized Block

CWE-1125: Excessive Attack Surface

CWE-1120: Excessive Code Complexity

CWE-1049: Excessive Data Query Operations in a Large Data Table

CWE-1067: Excessive Execution of Sequential Searches of Data Resource

CWE-1122: Excessive Halstead Complexity

CWE-1094: Excessive Index Range Scan for a Data Resource

CWE-1121: Excessive McCabe Cyclomatic Complexity

CWE-1060: Excessive Number of Inefficient Server-Side Data Accesses

CWE-1050: Excessive Platform Resource Consumption within a Loop

CWE-1108: Excessive Reliance on Global Variables

CWE-1052: Excessive Use of Hard-Coded Literals in Initialization

CWE-1123: Excessive Use of Self-Modifying Code

CWE-1119: Excessive Use of Unconditional Branching

CWE-1093: Excessively Complex Data Representation

CWE-1124: Excessively Deep Nesting

CWE-1077: Floating Point Comparison with Incorrect Operator

CWE-1173: Improper Use of Validation Framework

CWE-1116: Inaccurate Comments

CWE-1113: Inappropriate Comment Style

CWE-1078: Inappropriate Source Code Style or Formatting

CWE-1114: Inappropriate Whitespace Style

CWE-1110: Incomplete Design Documentation

CWE-1112: Incomplete Documentation of Program Execution

CWE-1111: Incomplete I/O Documentation

CWE-1068: Inconsistency Between Implementation and Documented Design

CWE-1099: Inconsistent Naming Conventions for Identifiers