This weakness occurs when developers hardcode sensitive data—such as API keys, database passwords, authentication tokens, or private encryption keys—directly…
This weakness occurs when developers hardcode sensitive data—such as API keys, database passwords, authentication tokens, or private encryption keys—directly into source code files. If source code is exposed through version control leaks, backup files, or accidental public repository commits, attackers gain immediate access to these credentials and can compromise systems, steal data, or escalate privileges.
Developers often hardcode credentials for convenience during development or testing, intending to remove them before deployment but forgetting to do so. Sensitive data may also be committed to version control systems (Git, SVN, etc.) where it persists in commit history even after being deleted from the current codebase. Source code exposure can occur through misconfigured cloud storage, publicly accessible backup files, decompiled binaries, or repositories accidentally pushed to public platforms. Once credentials are in version control history, they are extremely difficult to fully remove without rewriting the entire repository history.
Exposed credentials allow attackers to authenticate as the application, access databases directly, call third-party APIs on behalf of the service, or pivot to other systems that share the same credentials. A single hardcoded database password can lead to full data exfiltration. API keys may enable attackers to consume services at the victim's expense or impersonate the application to other systems. Private encryption keys compromise the confidentiality of encrypted data. Recovery requires rotating all exposed credentials across all systems that use them—a costly and time-consuming process.
import sqlite3
# Hardcoded database credentials
DB_USER = "admin"
DB_PASSWORD = "SuperSecret123!"
DB_HOST = "db.example.com"
def connect_to_database():
connection_string = f"postgresql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}/myapp"
conn = sqlite3.connect(connection_string)
return connWhy it's vulnerable:
The database password is stored as a plain-text constant in the source code, where it will be visible to anyone with access to the repository, backups, or compiled artifacts.
import sqlite3
import os
# Load credentials from environment variables
DB_USER = os.getenv("DB_USER")
DB_PASSWORD = os.getenv("DB_PASSWORD")
DB_HOST = os.getenv("DB_HOST")
def connect_to_database():
connection_string = f"postgresql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}/myapp"
conn = sqlite3.connect(connection_string)
return conn<?php
// Hardcoded API key and database password
define('API_KEY', 'sk_live_abc123xyz789');
define('DB_PASSWORD', 'MyDatabasePass456');
$api_url = 'https://api.example.com/v1/data?key=' . API_KEY;
$response = file_get_contents($api_url);
$db = new mysqli('localhost', 'root', DB_PASSWORD, 'myapp');
?>Why it's vulnerable:
Both the API key and database password are hardcoded as constants, making them visible in the source code and any backups or version control history.
<?php
// Load credentials from environment variables
$api_key = getenv('API_KEY');
$db_password = getenv('DB_PASSWORD');
$api_url = 'https://api.example.com/v1/data?key=' . urlencode($api_key);
$response = file_get_contents($api_url);
$db = new mysqli('localhost', 'root', $db_password, 'myapp');
?>.env file (or equivalent) for local development, and ensure it is listed in .gitignore to prevent accidental commits.
aws_access_key_id, password=, api_key) and block commits containing them.
git-secrets or TruffleHog to detect and remove them.
Check your Git repository history for files containing patterns like password=, api_key=, secret=, or token= using git log -p or automated scanning tools. Review any publicly accessible backups, Docker images, or compiled binaries to see if source code or configuration files are embedded. If you find exposed credentials, assume they have been compromised and rotate them immediately across all systems.
