Use of Hard-Coded Secrets Vulnerability
Play Agnostic Labs on this vulnerability with SecureFlag!
Description
The Use of Hard-Coded Secrets vulnerability occurs when an application embeds authentication secrets, such as passwords, API keys, cryptographic keys, or tokens, directly within its source code, configuration files, or binaries.
Hard-coded secrets are usually introduced for convenience during development, testing, or troubleshooting, but often remain in production systems. Once embedded, these secrets are difficult to rotate, are frequently reused across environments, and may be exposed through source code repositories, reverse engineering, backups, logs, or error messages.
This issue affects a wide range of technologies, including web applications, mobile apps, desktop software, firmware, scripts, infrastructure-as-code templates, and CI/CD pipelines. Because secrets are a fundamental security control, their improper handling can undermine the entire security model of an application or system.
The use of hard-coded credentials is a well-known authentication weakness and is explicitly addressed under OWASP - A07:2025 Authentication Failures, which highlights improper credential handling as a common cause of account and system compromise.
Impact
The impact of hard-coded secrets depends on the privileges associated with the exposed secret and where it is reused.
Potential consequences include:
- Unauthorized access to applications, APIs, databases, or third-party services.
- Privilege escalation if hard-coded credentials grant administrative or system-level access.
- Lateral movement within internal networks when secrets are reused across services.
- Data breaches involving sensitive or regulated information.
- Loss of trust, regulatory penalties, and incident response costs.
In many cases, attackers do not need to exploit a complex vulnerability; simply discovering the embedded secrets may be sufficient to compromise the system.
Scenarios
A common scenario involves a developer hard-coding database credentials into application source code. If this code is pushed to a public or shared repository, an attacker can retrieve the credentials and gain direct access to the database, bypassing application-level controls entirely.
Another typical case is a mobile application that contains an embedded API key to authenticate against a backend service. An attacker can decompile the application binary to extract the key, then abuse the API to access unauthorized data or consume services.
In embedded systems and firmware, default hard-coded administrative credentials may be identical across thousands of deployed devices. Once discovered, attackers can automate exploitation at scale, as has been observed in numerous IoT botnet campaigns.
Prevention
Preventing the use of hard-coded secrets requires both secure development practices and organizational controls.
- Secrets should be stored and managed using dedicated secret-management solutions (for example, secure vaults, cloud-native secret stores, or hardware security modules).
- Applications should retrieve secrets securely at runtime using environment variables, managed identities, or short-lived credentials.
- Where possible, applications should rely on centralized authentication mechanisms such as Single Sign-On (SSO) to avoid managing credentials directly.
- For service-to-service or user authentication, use standardized authorization frameworks such as OAuth 2.0 or OpenID Connect instead of static secrets.
- To detect hard-coded secrets before deployment, use code reviews and automated scanning tools.
Testing
Verify that authentication secrets are not embedded in application artifacts and are managed securely.
- OWASP ASVS: 13.3
- OWASP Testing Guide: Testing for Default Credentials, Review Webpage Content for Information Leakage