Use of Redundant Code
The product has multiple functions, methods, procedures, macros, etc. that contain the same code.
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. For example, if there are two copies of the same code, the programmer might fix a weakness in one copy while forgetting to fix the same weakness in another copy.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
In the following Java example the code performs some complex math when specific test conditions are met. The math is the same in each case and the equations are repeated within the code. Unfortunately if a future change needs to be made then that change needs to be made in all locations. This opens the door to mistakes being made and the changes not being made in the same way in each instance.
It is recommended to place the complex math into its own function and then call that function whenever necessary.
Weaknesses in this category are related to poor coding practices.
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability. Presence of these weaknesses could reduce the maintainability of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability, as documented in 2016 with the Automated Source Code Maintainability Measure ...
This view (slice) covers all the elements in CWE.
CWE identifiers in this view (slice) are quality issues that only indirectly make it easier to introduce a vulnerability and/or make the vulnerability more difficult t...
This view (slice) displays only weakness base elements.