4

I have seen a lot written about keeping hardcoded sensitive information(API key strings, database passwords) as Environment variables for security. I am a bit new to this concept and while I've seen a lot for rails, not so much on the PHP side.

Even PHP FOG uses this type of setup when creating the initial mysql DB information for a user.

I really don't understand where this is set however and how it is retrieved using any particular php webpage/application. I am really looking at this from the perspective of something like keeping my transaction email API keys and other information safe and usable across multiple pages.

For example, if I just create a config.php file and put it in my site root, is that really any different than calling on the key directly within my code? Where should the environment variables be set and what is the most efficient way in calling them? I'm also curious how this differs from SESSION variables?

Note: I am running a LAMP stack with Nginx paired.

Update 1: One of these users tends to think against using environment variables and just in "non-public" files but I really don't see how this is much different.

Update 2: Found this article as well which seems to make some general sense from a Windows perspective (assuming for *nix need to change the php include path?). Again though, what is the benefit in this rather than just hard coding the API Key directly into the PHP script anyway?

Community
  • 1
  • 1
JM4
  • 6,740
  • 18
  • 77
  • 125

1 Answers1

0

I'd say this is just more a flavor of system integration than related to concrete security.

Environment variables can be used to create a context a script runs in. The script itself then takes these as a (hidden) dependency.

So you can execute the same script in different environments (environmental settings) without changing any line of code (including but not limited to) php based configuration files.

For example when you deploy your scripts automatically, the deployment systems are normally able to set environment variables because the principle is common. You do not need to modify the deployment scripts so that they know of your specific configuration files so that they can change them.

From a security standpoint, there is not much of a difference. Environment variables can be access publicly as well as you could access a global variable inside the script.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • Alright - well security aside then - what is the recommended way of setting them? Within webroot/out of root? If one or the other, I don't see why it matters ultimately. – JM4 Nov 27 '12 at 22:18
  • Environment variables are in the process space of the system. That means, they are either set or not set. Where you set them is entirely up to you, for example you could conditionally run a script with the development environment setup because of a cookie or request header via the `.htaccess` file or the server configuration. – hakre Nov 27 '12 at 22:21