Secrets in configuration files

Secrets stored in configuration files such as config.yaml, application.yml, .env or settings.json can leak just like secrets in source code. These files are often committed under the mistaken assumption that they are harmless because they are not code.

When to use this guide

Passwords or tokens appear in config.yaml, application.yml or .env.
The real config.yaml is committed alongside config.yaml.example.
A configuration file directly contains production database passwords, API keys or OAuth secrets.

Remediation principles

Do not store real secret values in configuration files tracked by Git.
Commit only example files, not files containing actual values.
Configure the application to read secrets from environment variables or configuration files supplied at runtime.

Choose a detailed guide

If environment variables can replace the values: Secrets overview
If the application must keep a file format such as config.yaml: Runtime configuration file guide
If configuration files must be mounted in Kubernetes: Kubernetes guide
For Spring Boot using application.yml or application-prod.yml: Spring application.yml example
For Go services maintaining both config.yaml and config.yaml.example: Go config.yaml example

Minimum required actions

Revoke and replace secrets exposed in configuration files in the repository.
Keep real production configuration files out of Git.
Clearly separate the roles of example files and real files.
Prevent secrets from appearing in logs, error messages and debug output.

Developer responsibilities

Remove real secrets from configuration files.
Keep only the structure in example files, without actual values.
Update the application to read environment variables or configuration files supplied at runtime.
Check that configuration dumps, error logs and debug output do not include secret values.

Infrastructure and platform responsibilities

Supply real configuration files through a secure deployment path instead of Git.
Use .gitignore and deployment pipeline controls to prevent real configuration files from entering the repository again.
Choose Kubernetes, a secret manager or secure file delivery according to your operating standards.
Define secret rotation and redeployment or reload procedures.

Verification

Confirm that production configuration files are absent from the repository.
Check that example files do not contain copied production secrets.
Confirm that logs and error responses do not expose secret values.
After deployment, verify that the application reads secrets in the intended way.

Common mistakes

Copying production values into config.yaml.example
Adding a file to .gitignore but leaving the already committed file in Git
Assuming a configuration file is protected because it is in a ConfigMap or Docker image
Printing the entire configuration object in debug logs

Remediation steps for the owner

Revoke or disable exposed credentials and replace them first. Do not wait for the file cleanup or deployment changes below.

Remove actual secret values from the configuration files.
If a file containing real values reached the repository, assess the need to clean up Git history.
Revoke exposed secrets and issue new values.
Add real configuration files to .gitignore.
Apply the appropriate pattern from the detailed guide for your configuration method.

Example instructions for the owner

“Remove actual secrets from configuration files and keep production files out of Git.”
“If environment variables are not suitable, keep the configuration format but securely supply the real file at runtime.”
“Keep only the structure in config.yaml.example and exclude the real config.yaml from commits.”

Additional checks

Has the .env file already been committed?
Were real production values copied into example files?
Are configuration values printed in logs or error messages?