RestingOwl owl logo RestingOwl
July 13, 2026 · 8 min read · By RestingOwl Security Desk

Secure Configuration andSecrets Management Explained

ConfigurationSecrets ManagementSecurityOWASPDevSecOps
Quick answer: Secure configuration means shipping your app with safe settings and no leaked secrets. Keep passwords, API keys, and tokens out of your code and version history by using environment variables or a secret manager. Turn off debug mode and detailed errors in production, remove default accounts, and keep your dependencies up to date. Misconfiguration is one of the most common ways sites get breached.

Most breaches are not clever. They come from a forgotten default password, a secret key pushed to a public repository, or a debug page left switched on. These are configuration mistakes, and they are very common because settings live in many places and are easy to overlook. This guide gives you a clear, simple way to think about them. It maps to chapter V13 of the OWASP standard, which you can explore in the ASVS Explorer.

What Is a Secret and Where Do They Leak?

A secret is any value that grants access and must stay private: database passwords, API keys, signing keys, tokens, and encryption keys. Secrets leak in a few predictable places. They get hardcoded into source files. They get committed to git, where they live in the history forever even after you delete them. They get printed into logs. And they get shared over chat and email. The goal of secrets management is to keep these values out of all of those places.

Where secrets leakThe riskThe fix
Hardcoded in sourceAnyone with the code gets the keys.Load secrets from the environment or a secret manager at runtime.
Committed to gitThe secret stays in history even after deletion, and public repos are scanned by bots within minutes.Never commit secrets. Rotate any that were committed and use a secret scanner in your pipeline.
Printed in logsLog files and log services expose the secret to many people.Mask sensitive fields before logging. Never log tokens or passwords.
Baked into imagesA container image or build artifact carries the secret wherever it goes.Inject secrets at deploy time, not build time.

How Should You Store Secrets?

The right home for a secret depends on your size and setup, but the ranking is clear. At the least, load secrets from environment variables so they are not in your code. Better, use a dedicated secret manager such as AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, or your platform's built in secret store. A secret manager gives you access control, an audit trail of who read what, and easy rotation. Whatever you choose, add a .env style file to your .gitignore so local secrets never get committed by accident.

// Bad: secret sitting in the code and in git history
const dbPassword = "S3cr3t-prod-2026";

// Good: secret comes from the environment at runtime
const dbPassword = process.env.DB_PASSWORD;
if (!dbPassword) throw new Error("DB_PASSWORD is not set");

Why Does Rotating Secrets Matter?

Rotation means changing a secret on a regular schedule and straight away if you think it leaked. It matters because secrets do leak, and a secret that never changes gives an attacker unlimited time to use it. A secret manager makes rotation far easier because your app reads the current value at runtime instead of having it copied into many places. Plan for rotation from the start, even if you do it rarely, so that changing a key is a routine task and not an emergency.

What Are the Most Common Misconfigurations?

  • Debug mode on in production. Debug pages can reveal stack traces, configuration, and secrets. Turn debug off outside development.
  • Detailed error messages to users. Show a plain error to the user and keep the technical detail in your server logs. This connects to good server side practices across your app.
  • Default accounts and passwords. Remove or change every default login on databases, admin panels, and dashboards.
  • Open cloud storage. Storage buckets set to public are a frequent source of large data leaks. Default them to private.
  • Old or unpatched dependencies. Out of date libraries carry known holes. Track your dependencies and update them regularly.

Configuration and Secrets Checklist

Secure Configuration Checklist
  1. 1Keep all secrets out of source code and out of git history.
  2. 2Load secrets from environment variables or, better, a secret manager.
  3. 3Add env files and key files to gitignore, and scan commits for secrets.
  4. 4Rotate secrets on a schedule and immediately after any suspected leak.
  5. 5Turn off debug mode and detailed error pages in production.
  6. 6Remove or change all default accounts and passwords.
  7. 7Default cloud storage and databases to private, not public.
  8. 8Track dependencies and apply security updates promptly.
Go deeper: Configuration is chapter V13 of the OWASP ASVS, and it overlaps with the A05 Security Misconfiguration risk in the OWASP Top 10. See how it fits the wider standard in the ASVS Explorer.

References

  1. 1OWASP Secrets Management Cheat Sheet
  2. 2OWASP ASVS 5.0: V13 Configuration
  3. 3OWASP Top 10: A05 Security Misconfiguration

Q&A Section

Environment variables are a big improvement over hardcoding secrets in code, and they are fine for many apps. Their limits are that they can appear in process listings, crash dumps, or child processes, and they do not give you rotation or an audit trail. For sensitive systems, a dedicated secret manager is better because it adds access control, logging, and easy rotation.
No. Once a secret is in git history, deleting it in a new commit does not remove it from the history, and public repositories are scanned by bots within minutes. You must treat the secret as compromised and rotate it right away, then remove it from history and add scanning to prevent it happening again.
Detailed errors and stack traces can reveal your framework, file paths, database structure, and sometimes secrets, all of which help an attacker plan the next step. Show users a simple, generic message, and keep the full technical detail in server side logs where only your team can see it.
There is no single number, but a common approach is to rotate important secrets on a regular schedule, such as every few months, and immediately whenever you suspect a leak or a team member with access leaves. The key is to make rotation a routine, automated task rather than a rare emergency, which a secret manager makes much easier.
Copied!