Use of Hard-coded, Security-relevant Constants

Draft Base

Structure: Simple

Description

This vulnerability occurs when code directly embeds security-critical values like passwords, cryptographic keys, or access levels as raw numbers or strings, instead of using named constants or configuration files. This practice makes the code brittle and error-prone during updates or security reviews.

Extended Description

Hard-coding security values creates a maintenance nightmare. If a secret needs to be rotated or a permission level changed, developers must hunt through the entire codebase for every occurrence. Missing just one instance can introduce a security gap or break functionality. Once software is deployed, updating these embedded values often requires a full re-release, which may not even be possible in some environments. These constants also risk exposure if the code is ever leaked or reverse-engineered, turning a simple configuration change into a major breach. While SAST tools can flag the pattern, Plexicus uses AI to not only detect these hard-coded secrets but also suggest the specific code fix—like moving the value to a secure configuration manager—saving hours of manual refactoring and reducing human error.

Common Consequences 1

Scope: Other

Impact: Varies by ContextQuality Degradation

The existence of hardcoded constants could cause unexpected behavior and the introduction of weaknesses during code maintenance or when making changes to the code if all occurrences are not modified. The use of hardcoded constants is an indication of poor quality.

Detection Methods 1

Automated Static AnalysisHigh

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Potential Mitigations 1

Phase: Implementation

Avoid using hard-coded constants. Configuration files offer a more flexible solution.

Demonstrative Examples 1

ID : DX-215

The usage of symbolic names instead of hard-coded constants is preferred.

The following is an example of using a hard-coded constant instead of a symbolic name.

Code Example:Bad
C
c

If the buffer value needs to be changed, then it has to be altered in more than one place. If the developer forgets or does not find all occurrences, in this example it could lead to a buffer overflow.

Code Example:Good
C
c

In this example the developer will only need to change one value and all references to the buffer size are updated, as a symbolic name is used instead of a hard-coded constant.

Modes of Introduction

Implementation

Related Weaknesses

ChildOf:

Inappropriate Source Code Style or Formatting (CWE-1078)

Taxonomy Mapping

CERT C Secure Coding