Are Your Environment Secrets Actually Safe?

“The credentials are only in .env” sounds safer than it is.

An environment variable is not a vault. It is simply a way to pass configuration. Secrets can appear in build logs, container layers, debug output, CI artifacts, support screenshots, or frontend code shipped to every visitor.

A particularly dangerous assumption is that a secret is protected as long as it never entered Git. An API key can avoid the repository entirely and still end up in a public JavaScript bundle.

Where secrets commonly escape

• Build arguments remain visible in container images or image history.
• Variables with public frontend prefixes are embedded into browser code.
• Debug endpoints expose configuration or process environments.
• CI jobs print transformed values that bypass masking.
• Backups and support exports include .env files.
• Old credentials remain active after staff or agency changes.
• A shared “master secret” unlocks several systems at once.

Docker recommends secret or SSH mounts for build credentials instead of build arguments or normal environment variables. The OWASP Secrets Management Cheat Sheet recommends centralized management, short lifetimes, rotation, least privilege, and auditable access.

A quick project check

1. Search the built frontend for known key prefixes and internal service domains.
2. Inspect container history and image layers for build arguments and copied files.
3. Review which roles can read production secrets.
4. List old, unused, and never-rotated credentials.
5. Check logs, error tracking, and CI output for sensitive values.
6. Document how a compromised key would be revoked.
7. Test whether the application survives a rotation without prolonged downtime.

Good secret hygiene should be boring

A resilient setup separates development, test, and production credentials. Each service receives only the permissions it needs. Secrets are not baked into images; they are supplied securely at runtime. Rotation is documented and preferably automated.

Classification matters too. Not every environment variable is confidential. Public base URLs and feature flags may be safe to expose. Database passwords, private API keys, signing keys, and access tokens belong in an appropriate secrets-management system.

What Website-Pflichtencheck would review

A technical review follows the full chain: source code, build configuration, CI/CD, containers, frontend bundles, logs, hosting settings, permissions, and rotation.

This review is particularly useful after an agency change, repository leak, migration, new CI platform, or years of accumulated credentials.

“Not in Git” is only the beginning. If you cannot explain where a secret is created, used, logged, rotated, and revoked, the real security gap is the missing process.