Watch a database password leak through frontend JavaScript, a GitHub commit, a Docker image and a log line — then move it into a managed secret store, injected at runtime and rotated. See exactly where secrets escape.
Same database password, two worlds. Flip between bad practice and a managed secret store, and watch where the secret is exposed.
🖥️ Frontend JavaScriptEXPOSED
const DB_PASS = "Pr0d$3cr3t!v1"
🐙 GitHub repo (config.js)EXPOSED
DB_PASS=Pr0d$3cr3t!v1
🐳 Docker imageEXPOSED
ENV DB_PASS=Pr0d$3cr3t!v1
📜 Application logsEXPOSED
connecting to DB with Pr0d$3cr3t!v1
🚨 The password is sitting in the browser bundle, the git history, the image layers AND the logs. Four copies, all permanent. Rotating it means hunting down every copy.
What just happened
▹Secrets — DB passwords, API keys, signing keys, tokens — leak through everyday places: frontend code the browser downloads, a GitHub commit, a baked Docker image, or a log line. Once committed or shipped, assume it's compromised.
▹A managed secret store (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) keeps the value out of code entirely: the app references it and gets it injected at runtime. Code and images carry a reference, never the secret.
▹And rotate them. With a store, rotating a secret is one operation and every consumer picks up the new version — so a leaked secret has a short, bounded life.