Seems to be the general practice these days is to store secrets (e.g., DB, API credentials) in a .ENV file then load it to $_ENV and $_SERVER automatically. This popular library does that and it's even encouraged as best practice. This library takes it a step further and encrypts the value inside the .ENV file.

They say the whole purpose is to easily manage dev/production configs and to minimize config files being pushed to version control. On top of "never store sensitive credentials in your code".

One glaring issue about this is a simple injection of print_r($_SERVER)or print_r($_ENV) in your code will reveal everything. Or, if you forgot to delete phpinfo.php, all is lost! There are also other ways it could leak (e.g., logs).

I'm quite baffled that this practice is prevalent or maybe I'm just missing something.

Is there anything particularly wrong with the good old config.php stored outside document root? I mean you could put that in git ignore too and it's not going to be part of your code at all. You can even encrypt it too. Why use .ENV?


Here's an article that agrees to my sentiments

  • @ConorMancone It's not a duplicate. This question specifically questions the methodology of storing credentials in environment variables. That other question is about storing credentials in version control. – IMB Dec 6 at 17:33
  • It sounds like you're thinking of security in a binary fashion. The point of separating secrets, configs and code is to minimize security impacts, not create perfectly secure applications, which is impossible. Also, separating your code from your config is generally considered "good practice" in other programming languages. It's relatively common to include multiple languages in a project, and having a language-neutral secrets and config is normally much preferred than putting configs in code. – Steve Sether Dec 6 at 18:16
  • @SteveSether language-neutral secrets this is the only benefit I see from this. Other than that, it's high risk in my view. There's just too many possible leaks vs accidental version control commit. – IMB Dec 6 at 18:27
  • 1
    Possible duplicate of… from Server Fault. – Austin Hemmelgarn Dec 6 at 20:03

No Inherent Problems from a Security Perspective

If your application or its server is compromised, the attacker will likely be able to read everything in the config, including sensitive data such as passwords, tokens, or connection strings. This is true whether you use config files or environment variables.

If you ever suspected a compromise, you would scrub/reset your secrets regardless of whether your config is stored in files or environment variables.

Practical Reasons

The article you linked as an explanation offers practical reasons for using environment variables.

According to their recommendation, this approach reduces the risk of: bad commits (specifically, those containing config data), misconfigured deployments, and poor development practices.

To the extent that their recommendation prevents bad security behaviors, it is best to follow it. Security lapses are due to human error during deployment/maintenance as well as software bugs. If an automated process or a habit prevents a problem, it is the right thing to do.

  • this approach reduces the risk of: bad commits As I mentioned, you can also put config.php in your ignore file. I don't know but I still don't buy it. The security issues I have pointed out is a much higher risk than a bad commit for me. – IMB Dec 6 at 16:32
  • From your example, if people can inject like that, then you need to redeploy at the OS/container level and reset your passwords regardless. Dumping environment variables may be easier than finding a config file, but at that point you can't really trust anything the application can access anyway. That config file is not separated by a security barrier which would restrict the attacker in your scenario. – DoubleD Dec 6 at 18:54
  • Isn't one of the tenets of security is to make it harder for an attacker? Dumping ENV vs dumping config.php is like rainbowtabling an md5 hash vs bcrypt. The former is easier, the latter requires more guesswork. Also, how do you defend against accidental logging or output of environment data? E.g., if someone leaves whoops enabled in production, your credentials are there for the taking just like that. – IMB Dec 6 at 19:04
  • Your approach is security through obscurity, i.e., hoping the attacker won't know where to look. Unless there is a security barrier between the attacker and the config, the benefit is minimal. You seem to think locating a config file is a huge obstacle for an attacker; it is not. You're quibbling over a slight delay. If an attacker can shell out of your application, you need to fix the problem, sanitize everything, and redeploy. – DoubleD Dec 6 at 19:24
  • Your approach is security through obscurity It's not my primary approach by any means but a welcomed benefit. I'd take a few minutes delay vs 1 sec of var_dump($_SERVER). Anyway that's just one issue among others. BTW I updated my OP with an article I found for more info on why I think this is an issue – IMB Dec 6 at 19:34

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.