Managing secrets in applications

Application secrets include API keys, database credentials, signing keys, private keys, service account tokens and certificates. They need deliberate management because one leaked secret can give an attacker direct access to systems and data. The work is a lifecycle: identify a secret, store it safely, retrieve it through a managed system, rotate it on a schedule, and revoke it fast when something goes wrong.

Know what counts as a secret

A secret is any value that grants access, signs data, decrypts data or proves identity. Common examples include database passwords, OAuth client secrets, cloud access keys, webhook signing secrets, SSH keys, TLS private keys and encryption keys.

Configuration values are not all secrets. A public URL or feature flag may belong in ordinary configuration. A token that can reach production data does not. Classify secrets clearly so they get stronger handling than ordinary settings.

Do not hardcode secrets

Do not put secrets in source code, container images, client side bundles, test fixtures or documentation examples. Source control keeps history, so deleting a committed secret from the latest version does not remove it. The value still sits in earlier commits.

When a secret is committed, treat it as exposed and rotate it. Rewriting history with a tool like git filter-repo or BFG Repo-Cleaner addresses hygiene and compliance, but it does not undo the exposure on its own. Rotation is what actually removes the risk.

Use secret scanning in the IDE, in source control and in CI to catch mistakes early. Scanning is a safety net, not permission to store secrets in code.

Use a secrets manager

A secrets manager centralises storage, access control, auditing and rotation. It also gives applications a consistent way to retrieve secrets at runtime instead of reading them from scattered files.

Choose a retrieval design that fits the runtime. Server applications can fetch secrets from a managed service or a local agent, and a sidecar that refreshes the value periodically keeps a valid credential in memory without a redeploy. CI jobs can request short lived credentials for a single run. Client side code should not receive server side secrets at all.

Avoid spreading production secrets through environment files, chat messages or manual setup notes. Those channels are hard to audit and hard to clean up.

Prefer short lived credentials

Static credentials are easy to copy and hard to contain. Prefer short lived or dynamic credentials issued by identity based access, workload identity or federation. A dynamic database credential, for example, expires on its own, so a stolen value stops working without any manual cleanup.

Short lived credentials reduce the useful life of a leak and make rotation less disruptive, because the application already expects renewal. Pair them with least privilege so each credential carries only the access its workload needs.

For long lived secrets that cannot be removed, document ownership, purpose, expiry, rotation steps and emergency revocation steps.

Rotate and revoke safely

Rotation is the planned replacement of a secret. Revocation is the removal of trust from a secret, usually during an incident.

Design applications so rotation is routine. That may mean supporting multiple active keys during a transition, reloading secrets without a full deployment, and testing the rollback path before you need it.

When a secret is suspected to be exposed, revoke or rotate it promptly, then check logs for use of the old value. Log attempts to use a revoked secret so a leak shows up after the fact.

Protect secrets in logs and telemetry

Secrets often leak through error messages, debug logs, request dumps, crash reports and analytics events. A secrets manager does not help if the application prints the value on the next line.

Redact or mask known secret fields before logging. Avoid logging full headers, connection strings, tokens or signed URLs. Treat observability pipelines as sensitive systems, because they may receive secrets by accident.

Conclusion

Secrets management is a lifecycle problem, not a place to paste passwords. Identify what counts as a secret, keep it out of code, retrieve it through a managed system, prefer short lived credentials, make rotation a normal operation, and keep secrets out of your logs.