Use of Invariant Value in Dynamically Changing Context
This vulnerability occurs when code uses a fixed, unchanging value (like a hardcoded string, number, or reference) in a situation where that value should actually be flexible and adapt to different runtime conditions or environments.
Developers often hardcode values like file paths, configuration settings, API endpoints, or cryptographic keys for simplicity during initial development. The problem arises when the application is deployed across different stages (like development, testing, and production) or for different users, as these invariant values fail to adjust. This forces the same static value to be used everywhere, which typically breaks functionality, exposes sensitive data, or creates security misconfigurations. To prevent this, you should externalize all environment-specific values into configuration files, environment variables, or secure secret management services. This practice, central to DevOps and secure CI/CD pipelines, ensures your application can dynamically pull the correct database credentials, service URLs, or feature flags for each specific deployment context without requiring code changes.
Impact: Varies by Context
ID : DX-14
The following code is an example of an internal hard-coded password in the back-end:Code Example:
cCode Example:
javaID : DX-192
This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.Code Example:
c// Here we can inject code to execute.*
- PLOVER