Laravel 4.2 does it populating $_ENV
and $_SERVER
, Laravel 5.1 uses DotEnv to populate $_ENV
.
I am in fact working on a non laravel project and refactoring an existing app using laravel config package via composer. Currently, we have multiple files existing in folder higher than project root for storing sensitive info (so nothing is stored in git). So method that needs these sensitive keys currently looks like this:
processStripeCharge(){
$keys = include '../../keys/stripe.php';
.... }
which I want to replace with:
processStripeCharge(){
$keys = config('stripe');
.... }
and config/stripe.php:
<?php return [
'public' => $_ENV['STRIPE_PUBLIC']
...
];
Will the new way be any less secure than the old way?(I will have to answer this to my manager who is very security conscious)
Advantages:
- Using central config files is obviously a very pressing need.
- ...
Disadvantages: (security?)
- If dev would leave a
var_dump($_ENV);
littering around or aphpinfo();
all secrets will be left in the open which wasn't the case till now. - Similar to 1), if hacker would add that to file that is run in context of site (so all config is loaded), they would very easily grab the key. Currently, they would need a drop more work, by spotting the method including the current file and add a
var_dump($keys)
right there.
I personally would argue, that if hacker has access to server, we are anyway in big big trouble, and they would have no problem getting the keys with current system anyways.
Will it be any more secure if only $_ENV
is populated and not $_SERVER
?
A compromise I thought of would be to make config/stripe.php
like this:
<?php
$keys = include '../../keys/stripe.php';
return [
'public' => $keys['public']
...
];
So I have best of both worlds, $_ENV
is not getting populated + using config files