CWE VIEW: CISQ Quality Measures (2016)
This view outlines the most important software quality issues as identified by the Consortium for Information & Software Quality (CISQ) Automated Quality Characteristic Measures, released in 2016. These measures are derived from Object Management Group (OMG) standards.
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability. Show Details:
1128 - CISQ Quality Measures (2016)
Category - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures (2016) - Reliability - (1129) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) Weaknesses in this category are related to the CISQ Quality Measures for Reliability, as documented in 2016 with the Automated Source Code CISQ Reliability Measure (ASCRM) Specification 1.0. Presence of these weaknesses could reduce the reliability of the software. 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.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')) The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.Classic Buffer OverflowUnbounded Transfer 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.Unchecked Return Value - (252) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 252 (Unchecked Return Value) The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions. 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.Declaration of Catch for Generic Exception - (396) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 396 (Declaration of Catch for Generic Exception) Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. 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.Declaration of Throws for Generic Exception - (397) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 397 (Declaration of Throws for Generic Exception) Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. 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.Missing Initialization of a Variable - (456) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 456 (Missing Initialization of a Variable) The product does not initialize critical variables, which causes the execution environment to use unexpected values. 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.Uncontrolled Recursion - (674) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 674 (Uncontrolled Recursion) The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.Stack Exhaustion 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.Incorrect Type Conversion or Cast - (704) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 704 (Incorrect Type Conversion or Cast) The product does not correctly convert an object, resource, or structure from one type to a different type. 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.Missing Release of Resource after Effective Lifetime - (772) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 772 (Missing Release of Resource after Effective Lifetime) The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed. 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.Access of Memory Location After End of Buffer - (788) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 788 (Access of Memory Location After End of Buffer) The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer. 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.Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor - (1045) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1045 (Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor) A parent class has a virtual destructor method, but the parent has a child class that does not have a virtual destructor. 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.Modules with Circular Dependencies - (1047) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1047 (Modules with Circular Dependencies) The product contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies. 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.Initialization with Hard-Coded Network Resource Configuration Data - (1051) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1051 (Initialization with Hard-Coded Network Resource Configuration Data) The product initializes data using hard-coded values that act as network resource identifiers. 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.Invokable Control Element with Variadic Parameters - (1056) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1056 (Invokable Control Element with Variadic Parameters) A named-callable or method control element has a signature that
supports a variable (variadic) number of parameters or arguments. 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.Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element - (1058) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1058 (Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element) The code contains a function or method that
operates in a multi-threaded environment but owns an unsafe non-final
static storable or member data element. 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.Parent Class with References to Child Class - (1062) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1062 (Parent Class with References to Child Class) The code has a parent class that contains references to a child class, its methods, or its members. 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.Runtime Resource Management Control Element in a Component Built to Run on Application Servers - (1065) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1065 (Runtime Resource Management Control Element in a Component Built to Run on Application Servers) The product uses deployed components from application servers, but it also uses low-level functions/methods for management of resources, instead of the API provided by the application server. 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.Missing Serialization Control Element - (1066) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1066 (Missing Serialization Control Element) The product contains a serializable data element that does not
have an associated serialization method. 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.Empty Exception Block - (1069) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1069 (Empty Exception Block) An invokable code block contains an exception handling block that does not contain any code, i.e. is empty. 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.Serializable Data Element Containing non-Serializable Item Elements - (1070) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1070 (Serializable Data Element Containing non-Serializable Item Elements) The product contains a serializable, storable data element such as a field or member,
but the data element contains member elements that are not
serializable. 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.Floating Point Comparison with Incorrect Operator - (1077) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1077 (Floating Point Comparison with Incorrect Operator) The code performs a comparison such as an
equality test between two float (floating point) values, but
it uses comparison operators that do not account for the
possibility of loss of precision. 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.Parent Class without Virtual Destructor Method - (1079) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1079 (Parent Class without Virtual Destructor Method) A parent class contains one or more child classes, but the parent class does not have a virtual destructor method. 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.Class Instance Self Destruction Control Element - (1082) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1082 (Class Instance Self Destruction Control Element) The code contains a class instance that calls the method or function to delete or destroy itself. 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.Data Access from Outside Expected Data Manager Component - (1083) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1083 (Data Access from Outside Expected Data Manager Component) The product is intended to manage data access through a particular data manager component such as a relational or non-SQL database, but it contains code that performs data access operations without using that component. 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.Class with Virtual Method without a Virtual Destructor - (1087) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1087 (Class with Virtual Method without a Virtual Destructor) A class contains a virtual method, but the method does not have an associated virtual destructor. 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.Synchronous Access of Remote Resource without Timeout - (1088) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1088 (Synchronous Access of Remote Resource without Timeout) The code has a synchronous call to a remote resource, but there is no timeout for the call, or the timeout is set to infinite. 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.Persistent Storable Data Element without Associated Comparison Control Element - (1097) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1097 (Persistent Storable Data Element without Associated Comparison Control Element) The product uses a storable data element that does not have
all of the associated functions or methods that are necessary to support
comparison. 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.Singleton Class Instance Creation without Proper Locking or Synchronization - (1096) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1096 (Singleton Class Instance Creation without Proper Locking or Synchronization) The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once. 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.Data Element containing Pointer Item without Proper Copy Control Element - (1098) 1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures (2016) - Reliability) > 1098 (Data Element containing Pointer Item without Proper Copy Control Element) The code contains a data element with a pointer that does not have an associated copy or constructor method. Category - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures (2016) - Maintainability - (1130) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) Weaknesses in this category are related to the CISQ Quality Measures for Maintainability, as documented in 2016 with the Automated Source Code Maintainability Measure (ASCMM) Specification 1.0. Presence of these weaknesses could reduce the maintainability of the software. 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.Dead Code - (561) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 561 (Dead Code) The product contains dead code, which can never be executed. 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.Use of Redundant Code - (1041) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1041 (Use of Redundant Code) The product has multiple functions, methods, procedures, macros, etc. that
contain the same code. 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.Architecture with Number of Horizontal Layers Outside of Expected Range - (1044) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1044 (Architecture with Number of Horizontal Layers Outside of Expected Range) The product's architecture contains too many - or too few -
horizontal layers. 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.Modules with Circular Dependencies - (1047) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1047 (Modules with Circular Dependencies) The product contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies. 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.Invokable Control Element with Large Number of Outward Calls - (1048) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1048 (Invokable Control Element with Large Number of Outward Calls) The code contains callable control elements that
contain an excessively large number of references to other
application objects external to the context of the callable,
i.e. a Fan-Out value that is excessively large. 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.Excessive Use of Hard-Coded Literals in Initialization - (1052) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1052 (Excessive Use of Hard-Coded Literals in Initialization) The product initializes a data element using a hard-coded
literal that is not a simple integer or static constant element. 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.Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer - (1054) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1054 (Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer) The code at one architectural layer invokes code that resides
at a deeper layer than the adjacent layer, i.e., the invocation skips at least one
layer, and the invoked code is not part of a vertical utility layer that can be referenced from any horizontal layer. 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.Multiple Inheritance from Concrete Classes - (1055) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1055 (Multiple Inheritance from Concrete Classes) The product contains a class with inheritance from more than
one concrete class. 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.Invokable Control Element with Signature Containing an Excessive Number of Parameters - (1064) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1064 (Invokable Control Element with Signature Containing an Excessive Number of Parameters) The product contains a function, subroutine, or method whose signature has an unnecessarily large number of
parameters/arguments. 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.Class with Excessively Deep Inheritance - (1074) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1074 (Class with Excessively Deep Inheritance) A class has an inheritance level that is too high, i.e., it
has a large number of parent classes. 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.Unconditional Control Flow Transfer outside of Switch Block - (1075) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1075 (Unconditional Control Flow Transfer outside of Switch Block) The product performs unconditional control transfer (such as a
"goto") in code outside of a branching structure such as a switch
block. 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.Source Code File with Excessive Number of Lines of Code - (1080) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1080 (Source Code File with Excessive Number of Lines of Code) A source code file has too many lines of
code. 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.Critical Data Element Declared Public - (766) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 766 (Critical Data Element Declared Public) The product declares a critical variable, field, or member to be public when intended security policy requires it to be private. 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.Invokable Control Element with Excessive File or Data Access Operations - (1084) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1084 (Invokable Control Element with Excessive File or Data Access Operations) A function or method contains too many
operations that utilize a data manager or file resource. 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.Invokable Control Element with Excessive Volume of Commented-out Code - (1085) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1085 (Invokable Control Element with Excessive Volume of Commented-out Code) A function, method, procedure, etc. contains an excessive amount of code that has been
commented out within its body. 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.Class with Excessive Number of Child Classes - (1086) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1086 (Class with Excessive Number of Child Classes) A class contains an unnecessarily large number of
children. 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.Method Containing Access of a Member Element from Another Class - (1090) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1090 (Method Containing Access of a Member Element from Another Class) A method for a class performs an operation that directly
accesses a member element from another class. 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.Use of Same Invokable Control Element in Multiple Architectural Layers - (1092) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1092 (Use of Same Invokable Control Element in Multiple Architectural Layers) The product uses the same control element across multiple
architectural layers. 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.Loop Condition Value Update within the Loop - (1095) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1095 (Loop Condition Value Update within the Loop) The product uses a loop with a control flow condition based on
a value that is updated within the body of the loop. 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.Excessive McCabe Cyclomatic Complexity - (1121) 1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures (2016) - Maintainability) > 1121 (Excessive McCabe Cyclomatic Complexity) The code contains McCabe cyclomatic complexity that exceeds a
desirable maximum. Category - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures (2016) - Security - (1131) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) Weaknesses in this category are related to the CISQ Quality Measures for Security, as documented in 2016 with the Automated Source Code Security Measure (ASCSM) Specification 1.0. Presence of these weaknesses could reduce the security of the software. 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.Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal 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.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')) The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharactersOS Command Injection 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.Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSHTML InjectionCSS 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.Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.SQL injectionSQLi 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.Improper Control of Resource Identifiers ('Resource Injection') - (99) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 99 (Improper Control of Resource Identifiers ('Resource Injection')) The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.Insecure Direct Object Reference 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.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')) The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.Classic Buffer OverflowUnbounded Transfer 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.Improper Validation of Array Index - (129) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 129 (Improper Validation of Array Index) The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow 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.Use of Externally-Controlled Format String - (134) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 134 (Use of Externally-Controlled Format String) The product uses a function that accepts a format string as an argument, but the format string originates from an external source. 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.Unchecked Return Value - (252) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 252 (Unchecked Return Value) The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions. 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.Use of a Broken or Risky Cryptographic Algorithm - (327) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 327 (Use of a Broken or Risky Cryptographic Algorithm) The product uses a broken or risky cryptographic algorithm or protocol. 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.Declaration of Catch for Generic Exception - (396) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 396 (Declaration of Catch for Generic Exception) Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. 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.Declaration of Throws for Generic Exception - (397) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 397 (Declaration of Throws for Generic Exception) Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. 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.Unrestricted Upload of File with Dangerous Type - (434) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 434 (Unrestricted Upload of File with Dangerous Type) The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.Unrestricted File Upload 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.Missing Initialization of a Variable - (456) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 456 (Missing Initialization of a Variable) The product does not initialize critical variables, which causes the execution environment to use unexpected values. 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.Unchecked Input for Loop Condition - (606) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 606 (Unchecked Input for Loop Condition) The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping. 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.Improper Locking - (667) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 667 (Improper Locking) The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors. 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.Operation on a Resource after Expiration or Release - (672) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 672 (Operation on a Resource after Expiration or Release) The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked. 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.Incorrect Conversion between Numeric Types - (681) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 681 (Incorrect Conversion between Numeric Types) When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur. 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.Missing Release of Resource after Effective Lifetime - (772) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 772 (Missing Release of Resource after Effective Lifetime) The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed. 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.Memory Allocation with Excessive Size Value - (789) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 789 (Memory Allocation with Excessive Size Value) The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.Stack Exhaustion 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.Use of Hard-coded Credentials - (798) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 798 (Use of Hard-coded Credentials) The product contains hard-coded credentials, such as a password or cryptographic key. 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.Loop with Unreachable Exit Condition ('Infinite Loop') - (835) 1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures (2016) - Security) > 835 (Loop with Unreachable Exit Condition ('Infinite Loop')) The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. Category - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures (2016) - Performance Efficiency - (1132) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) Weaknesses in this category are related to the CISQ Quality Measures for Performance Efficiency, as documented in 2016 with the Automated Source Code Performance Efficiency Measure (ASCPEM) Specification 1.0. Presence of these weaknesses could reduce the performance efficiency of the software. 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.Static Member Data Element outside of a Singleton Class Element - (1042) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1042 (Static Member Data Element outside of a Singleton Class Element) The code contains a member element that is declared as static (but not final), in which
its parent class element
is not a singleton class - that is, a class element that can be used only once in
the 'to' association of a Create action. 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.Data Element Aggregating an Excessively Large Number of Non-Primitive Elements - (1043) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1043 (Data Element Aggregating an Excessively Large Number of Non-Primitive Elements) The product uses a data element that has an excessively large
number of sub-elements with non-primitive data types such as structures or aggregated objects. 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.Creation of Immutable Text Using String Concatenation - (1046) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1046 (Creation of Immutable Text Using String Concatenation) The product creates an immutable text string using string concatenation operations. 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.Excessive Data Query Operations in a Large Data Table - (1049) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1049 (Excessive Data Query Operations in a Large Data Table) The product performs a data query with a large number of joins
and sub-queries on a large data table. 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.Excessive Platform Resource Consumption within a Loop - (1050) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1050 (Excessive Platform Resource Consumption within a Loop) The product has a loop body or loop condition that contains a control element that directly or
indirectly consumes platform resources, e.g. messaging, sessions, locks, or file
descriptors. 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.Data Access Operations Outside of Expected Data Manager Component - (1057) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1057 (Data Access Operations Outside of Expected Data Manager Component) The product uses a dedicated, central data manager component as required by design, but it contains code that performs data-access operations that do not use this data manager. 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.Excessive Number of Inefficient Server-Side Data Accesses - (1060) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1060 (Excessive Number of Inefficient Server-Side Data Accesses) The product performs too many data queries without using efficient data processing functionality such as stored procedures. 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.Creation of Class Instance within a Static Code Block - (1063) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1063 (Creation of Class Instance within a Static Code Block) A static code block creates an instance of a class. 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.Excessive Execution of Sequential Searches of Data Resource - (1067) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1067 (Excessive Execution of Sequential Searches of Data Resource) The product contains a data query against an SQL table or view
that is configured in a way that does not utilize an index and may cause
sequential searches to be performed. 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.Data Resource Access without Use of Connection Pooling - (1072) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1072 (Data Resource Access without Use of Connection Pooling) The product accesses a data resource through a database without using a
connection pooling capability. 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.Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses - (1073) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1073 (Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses) The product contains a client with a function or method that contains a large number of data accesses/queries that are sent through a data manager, i.e., does not use efficient database capabilities. 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.Large Data Table with Excessive Number of Indices - (1089) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1089 (Large Data Table with Excessive Number of Indices) The product uses a large data table that contains an excessively large number of
indices. 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.Use of Object without Invoking Destructor Method - (1091) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1091 (Use of Object without Invoking Destructor Method) The product contains a method that accesses an object but does not later invoke
the element's associated finalize/destructor method. 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.Excessive Index Range Scan for a Data Resource - (1094) 1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures (2016) - Performance Efficiency) > 1094 (Excessive Index Range Scan for a Data Resource) The product contains an index range scan for a large data table,
but the scan can cover a large number of rows.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-788: Access of Memory Location After End of Buffer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer. This typically occurs when a pointer or its index is incremented to a position after the buffer; or when pointer arithmetic results in a position after the buffer. 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.
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)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Example 1 This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer. (bad code) Example Language: C void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr; char hostname[64]; in_addr_t inet_addr(const char *cp); /*routine that ensures user_supplied_addr is in the right format for conversion */ validate_addr_form(user_supplied_addr); addr = inet_addr(user_supplied_addr); hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET); strcpy(hostname, hp->h_name); This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker. Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476). Example 2 In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: (bad code) Example Language: C int returnChunkSize(void *) {
/* if chunk info is valid, return the size of usable memory, * else, return -1 to indicate an error */ ... int main() { ... }memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1)); ... If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788). Example 3 This example applies an encoding procedure to an input string and stores it into a buffer. (bad code) Example Language: C char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE); if ( MAX_SIZE <= strlen(user_supplied_string) ){ die("user string too long, die evil hacker!"); }dst_index = 0; for ( i = 0; i < strlen(user_supplied_string); i++ ){ if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&'; }dst_buf[dst_index++] = 'a'; dst_buf[dst_index++] = 'm'; dst_buf[dst_index++] = 'p'; dst_buf[dst_index++] = ';'; else if ('<' == user_supplied_string[i] ){ /* encode to < */ else dst_buf[dst_index++] = user_supplied_string[i]; return dst_buf; The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands. Example 4 In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing. (bad code) Example Language: C int processMessageFromSocket(int socket) {
int success;
char buffer[BUFFER_SIZE]; char message[MESSAGE_SIZE]; // get message from socket and store into buffer //Ignoring possibliity that buffer > BUFFER_SIZE if (getMessage(socket, buffer, BUFFER_SIZE) > 0) { // place contents of the buffer into message structure ExMessage *msg = recastBuffer(buffer); // copy message body into string for processing int index; for (index = 0; index < msg->msgLength; index++) { message[index] = msg->msgBody[index]; }message[index] = '\0'; // process message success = processMessage(message); return success; However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).
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.
CWE-1044: Architecture with Number of Horizontal Layers Outside of Expected Range
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis 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. While the interpretation of "expected range" may vary for each product or developer, CISQ recommends a default minimum of 4 layers and maximum of 8 layers. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
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.
CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
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.
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)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
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.
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 C (Undetermined Prevalence) C++ (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) Example 1 The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array. (bad code) Example Language: C char last_name[20];
printf ("Enter your last name: "); scanf ("%s", last_name); The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. Example 2 The following code attempts to create a local copy of a buffer to perform some manipulations to the data. (bad code) Example Language: C void manipulate_string(char * string){
char buf[24]; }strcpy(buf, string); ... However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter. Example 3 The code below calls the gets() function to read in data from the command line. (bad code) Example Language: C char buf[24]; }printf("Please enter your name and press <Enter>\n"); gets(buf); ... However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition. Example 4 In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file. (bad code) Example Language: C ...
struct hostent *clienthp;
char hostname[MAX_LEN]; // create server socket, bind to server address and listen on socket ... // accept client connections and process requests int count = 0; for (count = 0; count < MAX_CONNECTIONS; count++) { int clientlen = sizeof(struct sockaddr_in); int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen); if (clientsocket >= 0) { clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name); logOutput("Accepted client connection from host ", hostname); // process client request ... close(clientsocket); close(serversocket); ... However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.
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.
Relationship At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them. Terminology Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
CWE CATEGORY: CISQ Quality Measures (2016) - Maintainability
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability, as documented in 2016 with the Automated Source Code Maintainability Measure (ASCMM) Specification 1.0. Presence of these weaknesses could reduce the maintainability of the software.
CWE CATEGORY: CISQ Quality Measures (2016) - Performance Efficiency
Weaknesses in this category are related to the CISQ Quality Measures for Performance Efficiency, as documented in 2016 with the Automated Source Code Performance Efficiency Measure (ASCPEM) Specification 1.0. Presence of these weaknesses could reduce the performance efficiency of the software.
CWE CATEGORY: CISQ Quality Measures (2016) - Reliability
Weaknesses in this category are related to the CISQ Quality Measures for Reliability, as documented in 2016 with the Automated Source Code CISQ Reliability Measure (ASCRM) Specification 1.0. Presence of these weaknesses could reduce the reliability of the software.
CWE CATEGORY: CISQ Quality Measures (2016) - Security
Weaknesses in this category are related to the CISQ Quality Measures for Security, as documented in 2016 with the Automated Source Code Security Measure (ASCSM) Specification 1.0. Presence of these weaknesses could reduce the security of the software.
CWE-1082: Class Instance Self Destruction Control Element
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code contains a class instance that calls the method or function to delete or destroy itself. For example, in C++, "delete this" will cause the object to delete itself. This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1086: Class with Excessive Number of Child Classes
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis issue makes it more difficult to understand and maintain the software, 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. While the interpretation of "large number of children" may vary for each product or developer, CISQ recommends a default maximum of 10 child classes. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1074: Class with Excessively Deep Inheritance
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA class has an inheritance level that is too high, i.e., it has a large number of parent classes. This issue makes it more difficult to understand and 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. While the interpretation of "large number of parent classes" may vary for each product or developer, CISQ recommends a default maximum of 7 parent classes. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1087: Class with Virtual Method without a Virtual Destructor
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA class contains a virtual method, but the method does not have an associated virtual destructor. This issue can prevent the product from running reliably, e.g. due to undefined behavior. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1063: Creation of Class Instance within a Static Code Block
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis pattern identifies situations where a storable data element or member data element is initialized with a value in a block of code which is declared as static. This issue can make the product perform more slowly by performing initialization before it is needed. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1046: Creation of Immutable Text Using String Concatenation
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterWhen building a string via a looping feature (e.g., a FOR or WHILE loop), the use of += to append to the existing string will result in the creation of a new object with each iteration. This programming pattern can be inefficient in comparison with use of text buffer data elements. This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this could be influenced to create performance problem. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-766: Critical Data Element Declared Public
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product declares a critical variable, field, or member to be public when intended security policy requires it to be private. 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. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
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 C++ (Undetermined Prevalence) C# (Undetermined Prevalence) Java (Undetermined Prevalence) 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];
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.
CWE-1083: Data Access from Outside Expected Data Manager Component
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product is intended to manage data access through a particular data manager component such as a relational or non-SQL database, but it contains code that performs data access operations without using that component. When the product has a data access component, the design may be intended to handle all data access operations through that component. If a data access operation is performed outside of that component, then this may indicate a violation of the intended design. This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1057: Data Access Operations Outside of Expected Data Manager Component
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a dedicated, central data manager component as required by design, but it contains code that performs data-access operations that do not use this data manager. This issue can make the product perform more slowly than intended, since the intended central data manager may have been explicitly optimized for performance or other quality characteristics. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1043: Data Element Aggregating an Excessively Large Number of Non-Primitive Elements
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a data element that has an excessively large number of sub-elements with non-primitive data types such as structures or aggregated objects. This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "excessively large" may vary for each product or developer, CISQ recommends a default of 5 sub-elements. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1098: Data Element containing Pointer Item without Proper Copy Control Element
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code contains a data element with a pointer that does not have an associated copy or constructor method. This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1072: Data Resource Access without Use of Connection Pooling
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product accesses a data resource through a database without using a connection pooling capability. This issue can make the product perform more slowly, as connection pools allow connections to be reused without the overhead and time consumption of opening and closing a new connection. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-561: Dead Code
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterDead 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. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
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) Example 1 The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, 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"; }
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.
CWE-396: Declaration of Catch for Generic Exception
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterCatching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of a language's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
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 C++ (Undetermined Prevalence) Java (Undetermined Prevalence) C# (Undetermined Prevalence) Python (Undetermined Prevalence) Example 1 The following code excerpt handles three types of exceptions in an identical fashion. (good code) Example Language: Java try {
doExchange(); }catch (IOException e) { logger.error("doExchange failed", e); }catch (InvocationTargetException e) { logger.error("doExchange failed", e); catch (SQLException e) { logger.error("doExchange failed", e); At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows: (bad code) try {
doExchange(); }catch (Exception e) { logger.error("doExchange failed", e); }However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.
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.
CWE-397: Declaration of Throws for Generic Exception
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThrowing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. Declaring a method to throw Exception or Throwable makes it difficult for callers to perform proper error handling and error recovery. Java's exception mechanism, for example, is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
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 C++ (Undetermined Prevalence) Java (Undetermined Prevalence) C# (Undetermined Prevalence) Example 1 The following method throws three types of exceptions. (good code) Example Language: Java public void doExchange() throws IOException, InvocationTargetException, SQLException {
... }While it might seem tidier to write (bad code) public void doExchange() throws Exception {
... }doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement. Example 2 Early versions of C++ (C++98, C++03, C++11) included a feature known as Dynamic Exception Specification. This allowed functions to declare what type of exceptions it may throw. It is possible to declare a general class of exception to cover any derived exceptions that may be throw. (bad code) int myfunction() throw(std::exception) {
if (0) throw out_of_range(); }throw length_error(); In the example above, the code declares that myfunction() can throw an exception of type "std::exception" thus hiding details about the possible derived exceptions that could potentially be thrown.
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.
Applicable Platform For C++, this weakness only applies to C++98, C++03, and C++11. It relies on a feature known as Dynamic Exception Specification, which was part of early versions of C++ but was deprecated in C++11. It has been removed for C++17 and later.
CWE-1069: Empty Exception Block
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterAn invokable code block contains an exception handling block that does not contain any code, i.e. is empty. When an exception handling block (such as a Catch and Finally block) is used, but that block is empty, this can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. 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.
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)
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) Example 1 In the following Java example, the code catches an ArithmeticException. (bad code) Example Language: Java public class Main {
public static void main(String[] args) {
int a = 1;
int b = 0; int c = 0; try { c = a / b;
} catch(ArithmeticException ae) { } } } Since the exception block is empty, no action is taken. In the code below the exception has been logged and the bad execution has been handled in the desired way allowing the program to continue in an expected way. (good code) Example Language: Java public class Main {
public static void main(String[] args) {
int a = 1;
int b = 0; int c = 0; try { c = a / b;
} catch(ArithmeticException ae) { log.error("Divided by zero detected, setting to -1.");
c = -1; } } }
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.
CWE-1049: Excessive Data Query Operations in a Large Data Table
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product performs a data query with a large number of joins and sub-queries on a large data table. This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "large data table" and "large number of joins or sub-queries" may vary for each product or developer, CISQ recommends a default of 1 million rows for a "large" data table, a default minimum of 5 joins, and a default minimum of 3 sub-queries. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1067: Excessive Execution of Sequential Searches of Data Resource
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains a data query against an SQL table or view that is configured in a way that does not utilize an index and may cause sequential searches to be performed. This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1094: Excessive Index Range Scan for a Data Resource
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains an index range scan for a large data table, but the scan can cover a large number of rows. This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "large data table" and "excessive index range" may vary for each product or developer, CISQ recommends a threshold of 1000000 table rows and a threshold of 10 for the index range. 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.
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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1121: Excessive McCabe Cyclomatic Complexity
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis issue makes it more difficult to understand and/or 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. 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)
Relevant to the view "Software Development" (CWE-699)
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.
CWE-1060: Excessive Number of Inefficient Server-Side Data Accesses
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter |