CREDS01 Hard-coded Credentials in Config Files

What this means

SiteShadow found a credential stored directly in a config-like location (examples: .env, config.py, settings.yml, CI variables committed to repo, or "defaults" files).

Why it matters

• Config files are copied everywhere: repos, Docker images, CI artifacts, backups.
• Rotation becomes painful and teams delay it.
• One leak becomes many as secrets get re-used across environments.

Safer examples

1) Use environment variables (and keep .env out of git)

# .env (local only — DO NOT COMMIT)
DATABASE_URL=postgres://...

import os

DATABASE_URL = os.environ["DATABASE_URL"]

2) Use a secret manager for production

• AWS Secrets Manager / SSM Parameter Store
• GCP Secret Manager
• Azure Key Vault
• 1Password / Vault / Doppler, etc.

3) Separate config from secrets

Keep safe defaults in source, inject secrets at deploy time:

# config.yml (safe to commit)
service:
  logLevel: info

How SiteShadow detects it (high level)

• Flags credential-shaped values in common config formats (.env, YAML, JSON, INI, "settings" files).
• Looks for high-risk keys (password=, secret_key=, aws_secret_access_key=, PRIVATE_KEY=) with real values.
• Uses heuristics to avoid placeholders (e.g., "changeme", "example", obviously fake keys).

References

• OWASP Top 10: https://owasp.org/Top10/

---

← Back to Vulnerability Library