Laravel whoops output – How to hide. env passwords

As of Laravel 5.5.13, there’s a new feature that allows you to blacklist certain variables in config/app.php under the key debug_blacklist.

When an exception is thrown, whoops will mask these values with asterisks * for each character.

To activate this feature, add the next lines inside config/app.php

...
    'debug_blacklist' => [
        '_ENV' => [
            'APP_KEY',
            'DB_PASSWORD',
            'REDIS_PASSWORD',
            'MAIL_PASSWORD',
            'PUSHER_APP_KEY',
            'PUSHER_APP_SECRET',
        ],
        '_SERVER' => [
            'APP_KEY',
            'DB_PASSWORD',
            'REDIS_PASSWORD',
            'MAIL_PASSWORD',
            'PUSHER_APP_KEY',
            'PUSHER_APP_SECRET',
        ],
        '_POST' => [
            'password',
        ],
    ],
...

Save the file and clear the config cache with

php artisan config:clear

After this, all keys added inside debug_blacklist array will be replaced with asterisks (************)

3 thoughts on “Laravel whoops output – How to hide. env passwords

  1. I still have no clue of why an MVC framework prints all environment variables on a debug page. Apparently it’s just too hard to double-click the .env file in PHPStorm.

    It’s also the reason why barely 2 % of the websites worldwide is using Laravel. I’m migrating everything to ASP.NET Core for the moment

  2. @Pleterjan, I was wondering about this too but then I believe it is meant to make debugging easier for developers. In other words, this feature should only be turned on on your development machine.

    You could turn debugging off completely by setting “APP_DEBUG” to “false” in your ENV file (that flag is at the top of the ENV file).

    Nevertheless, I would prefer APP_DEBUG to be FALSE be default so that any developer who needs it can turn it on and ENDEAVOUR TO REMEMBER turning it off before deployment. Or alternatively, now that the debug_blacklist has been introduced, perhaps these sensitive data should be blacklisted by default, so anyone who wants it otherwise can whitelist them.

  3. By the way, this debug_blacklist does not mask blank entries. For instance, a blank db_password or AWS App Key will still be displayed as blank.
    Wouldn’t it be nice for it to truly mask every blacklisted parameter? Maybe use an arbitrary numbers of *’s for blank fields.

Leave a Reply

Your email address will not be published. Required fields are marked *