Environment variable
Also known as: env var, environment variables, env variable
An environment variable is a named value stored by the operating system that programs can read to learn about their surroundings, such as where to find other programs (PATH), the user's home folder, or which database to connect to.
Developers use environment variables to keep configuration and secrets such as API keys out of their code. While environment variables are simple and universal, accidentally leaking them, such as by committing a .env file to a public code repository, is a common cause of breaches.
Environment variable, explained at three levels
At home
Environment variables are like sticky notes on the fridge that every family member can read, such as 'spare key is under the mat' or 'groceries are in the garage'. When a program starts, the computer hands it a copy of these notes, so it knows where your home folder is or which folders to search for other programs. Change a note, and programs started afterward behave differently without being rewritten.
At work
An environment variable is a named setting stored by the operating system, such as a database address or a folder path, that programs read when they start. Developers use them to keep configuration and secrets like API keys outside the code. Businesses care because the same software can run in testing and production just by changing these values, but careless handling can leak passwords and keys.
At home
Every program starts with a small set of named values from the operating system, such as your username, home folder and temporary folder. These are environment variables. The most famous is PATH, a list of folders the system searches when you type a command. If a program's folder is not on that list, typing its name produces 'command not found', even though it is installed. Each program inherits a copy of its parent's environment when it starts.
At work
Developers use environment variables to separate configuration from code, following the Twelve-Factor App approach. The same code reads a database address or API key from the environment, so it can run in development, testing and production without changes. Locally, values often come from a .env file loaded by a library. In production, platforms inject them from secrets managers such as AWS Secrets Manager, Azure Key Vault or HashiCorp Vault at startup.
At home
API keys and passwords often live in environment variables and .env files, which makes them easy to expose by accident. They show up in screenshots of terminals, in screen shares, and in code pushed to public GitHub repositories, where bots scan for keys within minutes. Deleting the post does not help once someone has copied it. In my view, treat any key you have accidentally shown as compromised, and create a new one immediately.
At work
Environment variables are visible to the process and its children and can leak through crash dumps, debug pages, logs and process listings on shared hosts. Add .env files to .gitignore, enable secret scanning with push protection, and prefer runtime retrieval from a secrets manager, or mounted files with tight permissions, for sensitive values. Rotate exposed keys immediately, scope keys to minimal permissions, and never log the full environment. Short-lived credentials through workload identity remove many static secrets.
Real-world examples
At home
Sophie installed Python but got 'command not found.' Adding Python's folder to her PATH environment variable fixed it.
At work
Marcus reviews code at a Calgary startup. He found an API key committed in a .env file, rotated it, and added secret scanning to the repository.
Common confusions
- Environment variables are a secure place to store secrets. — They're better than hard-coding, but can leak through logs, crash reports, or child processes. Secrets managers are safer.
- Deleting a leaked key from code fixes the problem. — The key remains in version history and may already be copied. It must be revoked and replaced.
For analysts
I'd include secrets handling in development standards. A single leaked API key can expose customer data or rack up large cloud bills overnight.
History & origin
Environment variables appeared in Version 7 Unix in 1979 and were later adopted by MS-DOS and Windows, where variables such as PATH told the system where to look for programs. The 'Twelve-Factor App' guidelines, published by Heroku co-founder Adam Wiggins in 2011, recommended storing configuration in environment variables, which became standard in cloud and container development. Tools such as dotenv files made local development easier. As code hosting grew, leaked secrets in repositories became a major problem, and GitHub expanded secret scanning to automatically detect exposed keys. In my view, environment variables are a tiny feature with a big security footprint.