hmm... nobody knows about this new feature that was introduced recently to Laravel? anyone?

Laravel puts those configs into the tracked config files by default because it makes it easy to pick up and go with. You can however move those into this untracked file just like you would something else. Then within those config files call the $ENV key for what you want and all is fine.

Here is how this works:

First, you add these env config files to your .gitignore so they will never be tracked. (At least production, for development, meh, I'd track it.)

Second, create the env config file, and load up the array with your DB credentials, Stripe Keys, etc.

Third, go into your config files, then then call $ENV['key'] to assign the values.

For example, in database.php you could call 'username' => $ENV['DB_USERNAME'], to pull the value from your secure config into your actual config. This way, you can still use Config::get('database.mysql.username') for example to grab that data.

From what I understand, if your webserver decides to start displaying the contents of php files rather than parsing them then the details could be exposed (this could happen after server misconfiguration or maybe a php upgrade etc).

dot files are hidden files and shouldn't be served, so should reduce the possibility of this happening

having said that - I use config files :)

@Garbee, thank you for the details on how to implement this!

@elite123, thank you for the additional insight on why this new feature was introduced to Laravel. One clarification I have to your point is, can the sever misconfiguration create the risk that you described even if the config php files are not in the public folder? I can understand the possible risk if the config files are in public folder but normally these files are not accessible directly via http, isn't it?

Thanks again to both of you for the explanations.

Another attack vector is the git repo itself. If your .git folder gets out, then people could re-construct the config files. Meanwhile if you use an untracked file, there is no risk of it being re-constructed from that. Even without the leak risk, there is also just the risk that someone accidentally makes a hosted version public for some time.

So just for securing things within your repo itself this is a good idea.

I see this is 4 months old already, and I do not by any means wish to flog a dead horse, but I have just started using Laravel and read about these dot files.

I understand the security benefits of keeping this information in untracked files as far as Git goes, but is it not a security concern in and of itself to have this sensitive information pushed into the $_SERVER superglobal?

All of the key-value pairs returned by this file will automatically be available via the $_ENV and $_SERVER PHP "superglobals". 

The point is : the .env files should not be tracked with git (the default .gitignore file states that they should be ignored). That way your database password and other sensitive data doesn't appear in your public github repository :)

I think this is the only purpose of this feature.

patrict said: I understand the security benefits of keeping this information in untracked files as far as Git goes, but is it not a security concern in and of itself to have this sensitive information pushed into the $_SERVER superglobal?

I have the exact same concern. More opinions on that?