CWE-1106: Insufficient Use of Symbolic Constants
The source code uses literal constants that may need to change or evolve over time, instead of using symbolic constants.
Browse cwe weaknesses with official CWE context and Glexia analysis.
Search And Filters
Showing 50 of 969 CWE records · Page 17 of 20.
The source code uses literal constants that may need to change or evolve over time, instead of using symbolic constants.
The source code uses symbolic constants, but it does not sufficiently place the definitions of these constants into a more centralized or isolated location.
The code is structured in a way that relies too much on using or setting global variables throughout various points in the code, instead of preserving the associated information in a narrower, more local context.
The code contains a callable, block, or other code element in which the same variable is used to control more than one unique task or store more than one instance of data.
The product's design documentation does not adequately describe control flow, data flow, system initialization, relationships between tasks, components, rationales, or other important aspects of the design.
The product's documentation does not adequately define inputs, outputs, or system/software interfaces.
The document does not fully define all mechanisms that are used to control or influence how product-specific programs are executed.
The source code uses comment styles or formats that are inconsistent or do not follow expected standards for the product.
The source code contains whitespace that is inconsistent across the code or does not follow expected standards for the product.
The source code contains elements such as source files that do not consistently provide a prologue or header that has been standardized for the project.
The source code contains comments that do not accurately describe or explain aspects of the portion of the code with which the comment is associated.
The code contains a function or method whose signature and/or associated inline documentation does not sufficiently describe the callable's inputs, outputs, side effects, assumptions, or return codes.
The documentation does not sufficiently describe the techniques that are used for error handling, exception processing, or similar mechanisms.
The code uses too many unconditional branches (such as "goto").
The code is too complex, as calculated using a well-defined, quantitative measure.
The code contains McCabe cyclomatic complexity that exceeds a desirable maximum.
The code is structured in a way that a Halstead complexity measure exceeds a desirable maximum.
The product uses too much self-modifying code.
The code contains a callable or other code grouping in which the nesting / branching is too deep.
The product has an attack surface whose quantitative measurement exceeds a desirable maximum.
The source code declares a variable in one scope, but the variable is only used within a narrower scope.
The code is compiled without sufficient warnings enabled, which may prevent the detection of subtle bugs or quality issues.
The product contains code that is not essential for execution, i.e. makes no state changes and has no side effects that alter data or control flow, such that removal of the code would have no impact to functionality or correctness.
The product does not use, or incorrectly uses, an input validation framework that is provided by the source language or an independent library.
The ASP.NET application does not use, or incorrectly uses, the model validation framework.
The product performs CPU computations using algorithms that are not as efficient as they could be for the needs of the developer, i.e., the computations can be optimized further.
The product uses a function, library, or third party component that has been explicitly prohibited, whether by the developer or the customer.
This entry has been deprecated because it was a duplicate of CWE-908. All content has been transferred to CWE-908.
The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.
The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.
The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.
The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.
The product uses a cryptographic primitive that uses an Initialization Vector (IV), but the product does not generate IVs that are sufficiently unpredictable or unique according to the expected cryptographic requirements for that primitive.
The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
Hardware description language code incorrectly defines register defaults or hardware Intellectual Property (IP) parameters to insecure values.
The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.
A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.
The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.
The product manages resources or behaves in a way that indirectly creates a new, distinct resource that can be used by attackers in violation of the intended policy.
The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.
The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.
Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.
System configuration protection may be bypassed during debug mode.
The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.
The product saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by a spreadsheet product.
The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.