Open ash123456789 opened 5 years ago
Could you see a use case where this could be counter intuitive? For me personally showing environment variables in the debug environment isn't exactly a security concern unless a live site is set to debug which I think is a bigger concern + I think it's sometimes useless to see these env variables to check if they're being populated correctly etc.
Could you see a use case where this could be counter intuitive? For me personally showing environment variables in the debug environment isn't exactly a security concern unless a live site is set to debug which I think is a bigger concern + I think it's sometimes useless to see these env variables to check if they're being populated correctly etc.
This is more of preventative measure, since accidents do happen and the possibility of a production environment (or even staging) not being in production
mode is not 0.
It's worth considering if/how this change would affect Ignition (if at all), as we'll likely be installing Ignition and/or upgrading the boilerplate to Laravel 6.0 shortly.
I noticed on one of our projects that we weren't blacklisting environment variables and thought this would be beneficial to add to the boilerplate. This was added in Laravel 5.7.
debug_blacklist
to theconfig/app.php
file to hide environment variable values on debug pages, preventing any leak of the appropriate keys. This should be modified on a per-project basis to ensure API keys are covered. It replaces the values with asterisks..editorconfig
to match our internal style guide for indenting.