Using environment variables to store secrets instead of writing them directly into your code is one of the quickest and easiest ways to add a layer of protection to your projects. There are many ways to use them, but a properly utilized .env file is one of the best, and I’ll explain why.

They’re project scoped

Environment variables are a part of every major operating system: Windows, MacOS, and all the flavors of *nix (Unix, BSD, Linux, etc.). They can be set at an operating system level, user level, session level… It gets complicated, and where/how you define them matters to the scope in which they can be accessed.

This variety of scopes also creates the distinct possibility of variable collisions. If you’re looking for an environment variable named API_KEY, that could be getting re-defined in each scope, and if you’re not steeped in that OS, it’s extra work to be sure you’re not clobbering something someone set at a different scope that some other app or service needs.

.env files are only consumed at runtime and only in the context of the app that’s consuming them. That prevents them from clobbering any other environment variables on the system that might be consumed outside your app.

They can be "ignored"

If you’re working on a JavaScript application in Node, you can’t ignore your index.js file in the version control system. It contains essential code. But you can set your .gitignore file to have the Git system ignore your .env file. If you do that from the inception of your repository, you won’t commit secrets to the project’s Git history.

A better option is to include a .sample.env file that sets the variable names, but only includes dummy data or blanks. People cloning/forking and using the repository can get the secrets via another route, then cp .sample.env .env (in a terminal), and assign the real values to the proper variables in the ignored .env file.

They’re relocatable

While most systems will default to looking for the .env file in the root of the app’s primary directory, you can always have it a level or two higher. So, if for example, a server configuration error or code bug leaves it possible to view all the files at the root of your web app as a directory, the .env will not be there for easy pickings.

This is not an uncommon practice. SSH keys are stored by default at ~/.ssh (a "hidden" subdirectory of the home directory of the user) on Windows, Mac, and Linux. You do not need to move them into the root directory of a project that uses them.

A quick .env demo in Node

Let’s say your working directory for the app you’re building is ~/Documents/work/projects/games/tictactoe and tictactoe is the root directory for the app you’re building and your Git repository. You can put the .env in the next directory up, games. And while we generally call the file type .env, you can call it .toecreds if you want to make it a distinct file that other processes would never even think to touch. We'll use that in the demo.

Here’s how you’d do that in Node.js.

1. In your games/tictactoe directory, npm init (go with the defaults) and then npm install dotenv.
2. Create your .toecreds file in the games directory.
3. Fill the .toecreds file with information in the following format: VARIABLE_NAME=VALUE (no spaces). You can also start a line with # for a comment. Here's some sample code:  

# Leaderboard SaaS
LEADERBOARD_ENDPOINT=https://example.com/leaderboard/v1
LEADERBOARD_KEY=jknfwgfprgmerg…

4. At the top of your index.js (or whatever file is your launchpoint) in games/tictactoe, include the following lines:

require('dotenv').config({ path: '../.toecreds' });
console.log(process.env.LEADERBOARD_ENDPOINT);

Run your index.js (type node index.js at a command prompt in your games/tictactoe directory) and the endpoint URL will be output to the terminal. Meanwhile, the environment variables you set in it will not be available from the terminal.

Try adding a long timeout to the script and then running node index.js & to return control back to the terminal after invoking the script. While the script is running in that shell session, the environment variables available to the shell still do not contain the secrets. The secrets are scoped to your running application.

You can have dev, test, and prod credential sets, having your CI/CD tooling pull the correct keys for the deployment target from a secrets manager and write the .toecreds (or .env) file to the same relative directory.

And there you have it

The use of a .env file helps you keep your app's secrets from ever being committed to your version control and provides an additional layer of protection against your secrets being discovered by hackers or other prying eyes. It's a great addition to your developer / dev-ops toolbox.

Security Risks of Environment Variables in Production

While .env files provide excellent protection for local development, using environment variables for secrets in production environments introduces significant security vulnerabilities that developers must understand. Unlike the controlled local environment where .env files excel, production systems face different threat vectors that can expose secrets stored in environment variables.

The primary concern stems from process visibility—any user with sufficient privileges can inspect running processes and their environment variables using commands like ps -eww <PID> or accessing /proc/<pid>/environ on Linux systems. This means that secrets stored as environment variables become visible to system administrators, monitoring tools, and potentially malicious actors who gain system access.

Additionally, environment variables are inherited by child processes, violating the principle of least privilege. When your application spawns subprocesses or calls third-party tools, those processes automatically receive access to all parent environment variables, including sensitive secrets. This unintended exposure can lead to credential leakage through logging, error reporting, or malicious subprocess behavior.

For production deployments, consider integrating with dedicated secrets management solutions like GitGuardian, AWS Secrets Manager, HashiCorp Vault, or cloud-native alternatives that provide encrypted storage, access controls, and audit trails specifically designed for sensitive data protection.

Docker Secrets vs Environment Variables

Container orchestration platforms like Docker and Kubernetes have evolved beyond simple environment variable injection to provide more secure secrets management approaches. Docker secrets environment variables represent a fundamental shift from traditional environment variable patterns, offering encrypted storage and controlled access mechanisms that address many security concerns inherent in standard environment variable usage.

Docker's built-in secrets management stores sensitive data in the Docker daemon's encrypted storage and mounts secrets as files within containers at runtime. This approach eliminates the visibility issues associated with environment variables since secrets never appear in process lists or environment dumps. The secrets are only accessible to authorized containers and are automatically cleaned up when containers terminate.

Kubernetes takes this further with its native Secrets API, allowing you to store and manage sensitive information separately from pod specifications. You can mount Kubernetes secrets as files or expose them as environment variables, but the underlying storage remains encrypted and access-controlled through RBAC policies.

When implementing dockerfile secrets environment variables, consider using multi-stage builds with BuildKit's secret mount feature, which allows you to access secrets during build time without embedding them in the final image layers. This prevents secrets from persisting in image history while maintaining the convenience of environment-based configuration patterns.

Secrets Detection and Monitoring for Environment Variables

Even with proper .env file management, organizations must implement comprehensive secrets detection to identify when environment variables containing sensitive data are inadvertently exposed through code repositories, logs, or configuration files. GitGuardian's secrets detection capabilities specifically target common patterns where developers accidentally commit .env files or hardcode environment variable values directly in source code.

The challenge with environment variables secrets lies in their dual nature—they can contain both sensitive credentials and harmless configuration values. Effective detection requires understanding context and patterns that distinguish between DATABASE_URL=postgres://user:pass@host/db (sensitive) and NODE_ENV=production (harmless). Advanced detection engines analyze variable names, value patterns, and entropy levels to accurately identify potential secrets.

Monitoring should extend beyond static code analysis to include runtime detection of secrets in environment variables. This involves scanning process environments, container configurations, and deployment manifests for exposed credentials. Automated remediation workflows can immediately rotate compromised secrets and update affected systems when environment variable exposure is detected.

Implementing pre-commit hooks that scan for common environment variable secret patterns, combined with continuous monitoring of your codebase and infrastructure, creates multiple layers of protection against accidental exposure of sensitive data stored in environment variables.