Hardcoded Credentials
debt(d5/e5/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep, trufflehog, and gitleaks — all specialist SAST/secret-scanning tools. These are not default linters and won't catch the issue in a standard IDE or compile step, but they are well-established tools for this exact problem. Plain code review may catch obvious cases, but the credential may already be deep in git history before review happens.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix says move credentials to environment variables or a secrets manager and update .gitignore. However, common_mistakes highlight that rotating the credential without purging git history is insufficient — git filter-repo or BFG must be run, .env must be retroactively excluded, and all deployment configs (docker-compose, Kubernetes manifests) must be audited. This is more than a one-line patch but typically stays within one codebase/component rather than being a cross-cutting architectural rework.
Closest to 'localised tax' (b3). The hardcoded credential itself is a localised problem — typically one or a few files are affected. However, the remediation burden (purging git history, rotating the credential externally, updating CI/CD and deployment secrets) imposes a persistent but bounded tax. It does not reshape the entire codebase or impose an ongoing structural cost on every future maintainer once properly resolved.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The canonical misconception is that private repositories are safe for storing secrets. This is a widely held and plausible belief — private repos feel restricted and secure — but it is wrong because repos can be breached, forked, accidentally made public, or accessed by former employees. This directly contradicts the developer's intuition about access control providing security, making it a serious cognitive trap rather than a mere edge case.
Also Known As
TL;DR
Explanation
Hardcoded credentials appear in source code, config files committed to git, docker images, and CI/CD logs. Once in git history they are permanent — even deleting the file does not remove the commit. Secret scanning tools (GitHub, GitLab, truffleHog) automatically detect patterns like API keys and alert providers. The correct approach is runtime injection via environment variables or a secrets manager, never compile-time embedding.
Common Misconception
Why It Matters
Common Mistakes
- Committing .env files to version control — add .env to .gitignore before the first commit.
- Hardcoding credentials in docker-compose.yml or Kubernetes manifests committed to git.
- Using placeholder credentials that 'get replaced in production' but never do.
- Rotating the credential without removing it from git history — use git filter-repo or BFG.
Code Examples
// Hardcoded in source — permanent exposure:
$pdo = new PDO('mysql:host=db', 'root', 'supersecret123');
$client = new StripeClient('sk_live_abc123realkey');
define('ADMIN_PASS', 'letmein');// Runtime injection via environment variables:
$pdo = new PDO(
'mysql:host=' . getenv('DB_HOST'),
getenv('DB_USER'),
getenv('DB_PASS')
);
$client = new StripeClient(getenv('STRIPE_SECRET_KEY'));
// Or from a secrets manager:
$secret = $vault->getSecret('prod/stripe');