Hardcoded Secrets

Domain

Application & code

ROOTVIEL support

Heuristic — Pattern/presence detection, without a provenance or proof oracle.

Analysis family

code-src

CWE

CWE-798

OWASP

A07:2021-Identification and Authentication Failures, A05:2021-Security Misconfiguration

A hardcoded secret is any credential placed as a literal value inside material that is not designed to protect secrets: source files, configuration checked into version control, container images, client-side bundles, infrastructure-as-code, test fixtures, or CI definitions. The secret may be a database password, a cloud access key, a third-party API token, a signing or encryption key, or an SSH/TLS private key. Because the value lives with the code, its confidentiality is only as strong as the weakest copy of that code — and code is copied, forked, cached, logged, and leaked.

The defect is not that a secret exists but that it is embedded where it should never be: a location with broad read access, long retention, and no rotation story. A hardcoded secret in git history survives even after it is deleted from the current tree, so the exposure persists until the secret itself is revoked and rotated.

Secrets end up hardcoded in predictable places: a developer hurrying a prototype, a credential pasted into a config file "temporarily", a key baked into a Dockerfile or image layer, a token shipped in a front-end bundle, or an example value in documentation that turns out to be real. They also leak through adjacent channels — commit messages, logs, error traces, and client-visible build output.

• ▸Source code: a connection string, API key, or password assigned to a constant or default parameter.
• ▸Configuration committed to version control (.env files, settings files) instead of being injected at runtime.
• ▸Container images and build layers where a secret used at build time remains in a layer.
• ▸Client-side bundles and mobile apps, where any embedded secret is fully recoverable by users.
• ▸Infrastructure-as-code, CI/CD pipeline files, and test fixtures holding real credentials.

A secret is a bearer credential: possession is authorization. Security therefore depends on limiting who can possess it and being able to revoke it quickly. Source code fails both tests — it is widely readable within an organisation and often beyond, and it is retained indefinitely in version history. The correct design separates the secret from the code entirely: the code references a secret by name and obtains its value at runtime from an environment variable, a secrets manager, or an injected mount, so the code can be shared freely while the value is governed independently and rotated without a code change.

Detecting hardcoded secrets is where this class differs from the injection flaws: there is no source-to-sink dataflow, only the presence of a sensitive literal. That makes it a genuine pattern/presence problem — regular expressions matched against known credential formats (recognisable key prefixes, PEM headers), plus entropy analysis for high-randomness strings that look like secrets. This is honest heuristic detection: it reliably flags many real secrets and reliably produces false positives (random-looking test data) and false negatives (secrets without a recognisable shape). A validity check against the issuing service turns a candidate into a confirmed live secret.

Bearer credential

A secret where holding it is sufficient to authenticate; its only defences are limited distribution and fast revocation.

Secrets manager

A system that stores secrets outside code, controls access, and supports rotation and auditing; code fetches values at runtime.

Entropy heuristic

Flagging high-randomness strings as likely secrets — catches unknown formats but also random-looking non-secrets (false positives).

Validity check

Confirming a candidate secret still authenticates to its service, which upgrades a pattern match to a confirmed live exposure.

The root cause is placing a bearer credential in material whose read access and retention the credential’s security model cannot tolerate. The developer treats the secret as part of the program’s configuration and writes it inline for convenience, conflating "the code needs this value" with "the value should live in the code". The fix is to decouple the two: the code names the secret; an external system supplies and governs the value.

A reinforcing cause is version control’s permanence. Once committed, a secret is in history on every clone and mirror; removing it from the latest commit does not undo the exposure. This is why the only correct response to a committed secret is to revoke and rotate it, treating the embedded value as already compromised, rather than merely deleting the line.

1. 1A secret is committed into a repository, baked into an image, or shipped in a client bundle.
2. 2An attacker gains read access to that material — a public or leaked repo, a pulled image, a forked project, a decompiled app, or an insider with ordinary code access.
3. 3The attacker extracts the literal value, often with automated scanners that continuously crawl public sources for credential patterns.
4. 4The attacker uses the bearer credential directly against the issuing service — the cloud account, the database, the third-party API — with the privileges the credential grants.
5. 5Because possession is authorization and the secret may not be rotated for a long time, the access persists until the exposure is noticed and the secret revoked.

Automated harvesting makes timing unforgiving: public credentials are frequently found and abused within minutes of being pushed, so the window between commit and compromise can be very short.

A synthetic, illustrative module that embeds credentials as literals. The values travel with the code into version history and any build artifact:

synthetic — placeholder values; illustrates the flaw
// UNSAFE: secrets embedded as literals; they live in git history forever.
const config = {
  dbUrl: "postgres://app:S3cr3t-Placeholder@db.internal:5432/app",
  apiKey: "EXAMPLE_KEY_0000000000000000000000",   // bearer credential in source
  jwtSigningKey: "hunter2-placeholder-not-a-real-key",
}

// Even if a later commit deletes these lines, the values remain recoverable
// from the repository history on every clone, fork, and mirror.
module.exports = config

The fix is to reference secrets by name and resolve them at runtime from the environment or a secrets manager, failing fast if a required value is absent. The code becomes safe to share; the values are governed and rotated independently.

synthetic — secrets resolved at runtime, nothing embedded
// SAFER: the code names secrets; an external system supplies the values.
function required(name) {
  const v = process.env[name]
  if (!v) throw new Error("missing required secret: " + name)
  return v
}

const config = {
  dbUrl: required("DB_URL"),            // injected from the environment / secrets store
  apiKey: required("THIRDPARTY_API_KEY"),
  jwtSigningKey: required("JWT_SIGNING_KEY"),
}

// .env files and real values are git-ignored and never committed.
// In production, a secrets manager injects values and supports rotation.
module.exports = config

• ▸Account and data compromise: a leaked cloud key or database credential grants direct access with the secret’s privileges.
• ▸Signing-key abuse: a leaked JWT/signing or code-signing key lets an attacker forge trusted tokens or artifacts.
• ▸Persistent exposure: secrets in version history remain usable until revoked, across every clone and fork.
• ▸Supply-chain and lateral movement: one embedded credential can unlock CI systems, registries, and downstream services.

Detection is a presence problem, not a dataflow one. Secret scanners combine format-specific patterns (recognisable key prefixes, PEM headers, connection-string shapes) with entropy analysis for high-randomness strings. Scan the whole history, not just the working tree, since the exposure lives in old commits; scan container images and build artifacts too. Because patterns and entropy both produce false positives, a validity check — attempting to use the candidate against its service in an authorised test — is what confirms a live secret. This is honest heuristic detection: strong at flagging candidates, weak at deciding significance without the validity step.

This entry is reference material within an application/code domain that ROOTVIEL does not cover with a verified, execute-and-prove engine — that engine is focused on the AI/agentic and Web3 domains. Hardcoded-secret detection, however, is one place where an honest heuristic is genuinely appropriate: pattern and entropy scanning is a legitimate presence detector, so this entry is marked heuristic rather than educational. The caveat is that a heuristic flags candidates; it does not prove a secret is live or significant without a validity check, and it will both miss unusual formats and over-report random-looking non-secrets.

Keep secrets out of code, govern them externally, and assume anything committed is already exposed.

• ▸Preventive: store secrets in a managed secrets store (or injected environment) with access control, auditing, and rotation; the code references a name, never a value.
• ▸Preventive: git-ignore local secret files, use short-lived and least-privilege credentials, and prefer workload identity over long-lived keys where available.
• ▸Preventive: never embed secrets in client-side bundles or mobile apps — anything shipped to the client is recoverable.
• ▸Detective: run a secret scanner as a pre-commit hook and in CI over the full history and over images/artifacts.
• ▸Corrective: when a secret is found committed, revoke and rotate it immediately and treat all its past access as suspect; removing the line is not remediation.

Verify by scanning the full history, working tree, container images, and client bundles and confirming no live secret remains; for each previously found secret, confirm it has been revoked and rotated (a validity check against the service should now fail). Confirm the scanner runs in CI and as a pre-commit hook so new secrets are blocked. Report as "no live secret detected by the scanner across the scanned surface", acknowledging that a heuristic can miss unusual formats.

• ▸Deleting a committed secret from the latest commit but not revoking it, leaving it live in history.
• ▸Moving a secret to an environment variable while logs, error pages, or debug endpoints still expose the environment.
• ▸Embedding a secret in a client-side or mobile bundle and assuming obfuscation protects it.
• ▸Scanning only the current tree, missing secrets in old commits, images, and build artifacts.
• ▸Treating every scanner hit as critical (alert fatigue) or dismissing hits without a validity check (missing live ones).

Hardcoded secrets undermine controls elsewhere: a leaked signing key defeats the integrity checks that protect against insecure deserialization, and leaked cloud credentials amplify SSRF by handing over the very identity SSRF tries to reach. It is both an authentication failure (A07) and a misconfiguration (A05), and unlike the injection classes it is detected by presence, not by a source-to-sink path.