Hardcoded Secrets Security Check (CWE-798)
What this checks
Protects against credentials, API keys, and secrets embedded directly in source code.
Hardcoded secrets end up in version control history, build artifacts, and container
images. Once committed, secrets are effectively public — even if the commit is reverted,
the secret remains in git history.
Vulnerable patterns
- String literal that resembles a production API key, access token, or session secret assigned to a constant
- Hardcoded password or shared-secret literal used as the only credential check
- Connection string with embedded username and password committed to source
- Private key material (PEM, PKCS#8, SSH) pasted inline as a string literal
- Cloud-provider access keys, OAuth client secrets, or webhook signing keys in source or config files
Fix immediately
Flag the hardcoded secret and explain the risk. Translate the principles below to the
audited file's language and deployment environment — use that stack's documented secret
loader, env-var helper, or secrets-manager client.
For each finding, establish these properties:
- Secrets are loaded from outside the source tree. Environment variable,
secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password), KMS, or OS
keystore. No string literal that resembles a real credential appears in source
— not in code, not in config files, not in test fixtures.
- Missing secrets fail loudly at load time, not silently at first use. A
required-env lookup with no fallback, a required-field check, or an early
fatal log guarantees a misconfigured deploy crashes immediately rather than
running with an empty string that mysteriously fails later.
- Test fixtures use obviously fake values — placeholder strings that read as
"do not use" — that cannot be mistaken for production credentials and will
never unlock a real service if leaked.
- Rotation does not require a code change. If rotating the credential means
editing source and redeploying, the secret is effectively hardcoded even if
it's technically loaded through a constant. Rotation happens by updating the
external store and restarting.
Verification
References
1---2name: hardcoded-secrets3description: Detects API keys, passwords, tokens, and credentials embedded directly in source code. Use when writing code that contains API keys, passwords, tokens, connection strings, or private keys as string literals. Also invoke when embedding credentials in configuration files, environment setup scripts, or test fixtures that could be committed to version control.4---56# Hardcoded Secrets Security Check (CWE-798)78## What this checks910Protects against credentials, API keys, and secrets embedded directly in source code.11Hardcoded secrets end up in version control history, build artifacts, and container12images. Once committed, secrets are effectively public — even if the commit is reverted,13the secret remains in git history.1415## Vulnerable patterns1617- String literal that resembles a production API key, access token, or session secret assigned to a constant18- Hardcoded password or shared-secret literal used as the only credential check19- Connection string with embedded username and password committed to source20- Private key material (PEM, PKCS#8, SSH) pasted inline as a string literal21- Cloud-provider access keys, OAuth client secrets, or webhook signing keys in source or config files2223## Fix immediately2425Flag the hardcoded secret and explain the risk. Translate the principles below to the26audited file's language and deployment environment — use that stack's documented secret27loader, env-var helper, or secrets-manager client.2829For each finding, establish these properties:30311. **Secrets are loaded from outside the source tree.** Environment variable,32 secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password), KMS, or OS33 keystore. No string literal that resembles a real credential appears in source34 — not in code, not in config files, not in test fixtures.352. **Missing secrets fail loudly at load time, not silently at first use.** A36 required-env lookup with no fallback, a required-field check, or an early37 fatal log guarantees a misconfigured deploy crashes immediately rather than38 running with an empty string that mysteriously fails later.393. **Test fixtures use obviously fake values** — placeholder strings that read as40 "do not use" — that cannot be mistaken for production credentials and will41 never unlock a real service if leaked.424. **Rotation does not require a code change.** If rotating the credential means43 editing source and redeploying, the secret is effectively hardcoded even if44 it's technically loaded through a constant. Rotation happens by updating the45 external store and restarting.4647## Verification4849- [ ] No string literal in the code resembles a production API key, password, token, private key, or connection string with embedded credentials50- [ ] All credentials are loaded from environment variables, secrets managers, or encrypted configuration — never from source code51- [ ] Test fixtures use obviously fake values that cannot be mistaken for real credentials5253## References5455- CWE-798 ([Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html))56- CWE-259 ([Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html))
thejefflarson