DEV Community

4 Reasons Not To Use Environment Variables

Ben Brazier on August 02, 2022

Environment variables are a simple way to configure software. They let you set a variable in the shell so that any processes you run can use the va...

Read full post

Sylvie Fiquet • Aug 2 '22 • Edited

I am a bit uncomfortable with this, because this is an article for beginners and, although it makes a good case for config files, there is no mention of when it's a bad idea.

So for anybody who doesn't know: Never store secret info such as passwords or API keys in your files. Store them in environment variables, where hackers can't access them.

Ben Brazier • Aug 2 '22 • Edited

This is based on the assumption that environment variables aren't written to files. However, they are written to files in /proc/pid/environ which is why I don't think that environment variables should be considered more secure than files.

Sylvie Fiquet • Aug 2 '22

Oh I see. I should have paid more attention to the devops tag, that's where you're coming from. I guess your security concerns are at a different level.

My comment was made in the context of JavaScript/React development, which incidentally is a big chunk of the developer community on DEV, so it's likely some of your readers will come from that background.

In that context, code often lives on public repositories on the web, e.g. GitHub, so it's very important to know that you should not commit secrets to the repo (a common mistake). Because the source is public, secrets in config files are a no-no. Typically when deploying on third party platforms (e.g. Heroku, Vercel, Netlify...), secrets are provided through environment variables, so that's what I was talking about.

webbureaucrat • Aug 2 '22

Even in private repositories, it's very important not to commit secrets! What's the first thing you do when a service you use announces they've been accidentally logging passwords? You change your password immediately because the risk of your password ever having been stored on a web server in clear text is way too great, even for something like your personal Twitter.

How much worse would it be to store all of your database passwords or API keys unencrypted and unhashed on a third party's web server, where lots of their employees and contractors have access to the contents and where you have no visibility into their security practices?

Ben Brazier • Aug 2 '22

Public or private repositories should still need to pull in the secrets at package time whether it is through files or not.

I'm not saying store secrets in Git, in the same way I'm not saying to store compiled code in Git. Git is the starting point where this article refers to the end point of how software should be configured when it is running on a host.

Ben Brazier • Aug 2 '22

Of course nobody should commit secrets to Git.

Jean-Michel 🕵🏻‍♂️ Fayard • Aug 2 '22

Secrets should always be stored in environment variable

JSON is also bad for storing configuration data : no comments allowed, people almost never provide a JSON schema.

YAML has a different set of problems.

I tend to use TOML or properties files for simple stuff.

Ben Brazier • Aug 2 '22

Storing secrets in environment variables doesn't improve security.

This article isn't about the differences between JSON/YAML/TOML.

Keff • Aug 2 '22

Neither does storing them in JSON/YAML, in terms of security they're mostly the same

Rense Bakker • Aug 2 '22

In javascript/typescript I like to combine all ways to provide environment variables, using a sweet library called yargs :D

import dotenv from "dotenv"
import yargs from "yargs"
import fs from "fs"

dotenv.config()

const args = yargs
  .env() // parse process.env
  .middleware((argv) => {
    const configPath = "./config.json"
    if(fs.existsSync(configPath)){
      try {
        // parse options from config file
        return { ...JSON.parse(fs.readFileSync(configPath, 'utf-8')), ...argv }
      } catch(e){
        console.error('Error parsing config file')
      }
    }
    return argv
  }, true)
  .options({
    'port': { alias: 'p', type: 'number', default: 80 },
    'corsOrigin': { alias: 'o', type: 'string', default: "http://localhost:3000" },
    // etc... parses command line options
  })
  .help()
  .argv

not sure if such a library exists for python though.

Keff • Aug 2 '22 • Edited

How are JSON files more secure than envs? It makes no sense to me.

Ben Brazier • Aug 2 '22

They aren't, there is no meaningful difference in regards to security.

Dillon Barnes • Aug 2 '22

You could make a good argument that JSON is worse as you can't add comments to organise your variables...

Ben Brazier • Aug 2 '22

You can't add comments to envs?

Dillon Barnes • Aug 3 '22

You can. Use a pound sign (#)

Bradley Burgess • Aug 4 '22

Thanks. This only works if you control your hosting environment though, ie a dedicated / VPS server. If you're using e.g. Heroku, environment variables are your only choice for secrets, yes? Or do you propose something different?

Ben Brazier • Aug 4 '22

If environment variables are your only option then fair enough. However, I would be surprised if you can't add configuration files to a Heroku package.

Raí B. Toffoletto • Aug 3 '22

As everything in life... find a balance.

ENV is good for some things, and yes sometimes global state is necessary (not in the example provided), but I agree most of our configuration should be in a JSON or YAML.

But point ONE makes no sense to me. Both files and ENV need to be parsed. When you read a JSON file in python or node for example, it's just a bunch of strings values that need to be parsed to native types. Doesn't matter if is done under the covers or you do yourself 😉.

Also, point FOUR is the strength of ENV. Use that to your advantage.