1

I just started using laravel's lumen and managed to make it work both locally and on a server, when I was about to start exploring it, my index.php consisted in just:

$app = require __DIR__."/../lumenTest/bootstrap/app.php";
$app->run($app->make('request'));
echo $myundefinedvariable;

Which displays a ErrorException: Undefined variable: myundefinedvariable, but inside the "...at Application->Laravel\Lumen\Concerns{closure}" window I can see a giant wall of text with stuff like:

... 'APP_KEY' => 'fake0BqKgHeC72EmT7039B6pDCsJ90key' , ...,  'DB_PASSWORD' => 'secret', ...

And my first thoughts were, maybe it is because im running it localy with XAMPP or something, so I went and tried it on the server and the same thing happened.

Is it normal that sensitive data from my .env file gets shown to everyone after doing any php error?

Is there a way to avoid this happening? (different than not having any PHP errors, because I tend to have them a lot).

Additional info:

  • PHP version 7.1.12
  • Lumen (5.6.1) (Laravel Components 5.6.*)
  • The directory "lumenTest" is one level above my www or public and there is where the .env is located, the site is on a Linux server shared host
ajax333221
  • 11,436
  • 16
  • 61
  • 95
  • Possible duplicate of [How to hide .env passwords in Laravel whoops output?](https://stackoverflow.com/questions/46407009/how-to-hide-env-passwords-in-laravel-whoops-output) – ajax333221 Feb 23 '18 at 17:51

2 Answers2

1

No, that's not normal. Professional developers consider this an amaturistic behavior. That's the exact reason why companies don't even consider using Laravel.

Many people (including me) already notified them that this is really not-done, but the developers don't really seem to care. In fact it's the only framework in the world that thinks it's OK to print critical information in a debug page. Surely a visitor should never see stack traces, sql queries, pieces of code... But environment variables are confidential and should never end up in a HTTP response.

The best advice I have is to use a professional MVC framework like ASP.net, codeigniter, or yii, since there's no telling what the Laravel devs also think is OK to do...

If on the other hand you do decide to use Laravel anyway, there's a package that counters this: https://github.com/GlaivePro/Hidevara It's real easy to setup, just make sure you don't forget the app->extend instruction. On a production server you must not run "composer install" but instead "composer instal --no-dev". This way filp/whoops will (should, hopefully) not be installed and cannot be triggered.

For professional development, i surely recommend not to use Laravel since the bar of what they think is acceptable seems to be very low.

As a sidenote: the developers claim that nothing can go wrong when APP_DEBUG=false, but incidents in the past have shown that the whoops handler can be triggered when debug mode is disabled. https://www.google.com/amp/s/blog.hacken.io/dangers-of-laravel-debug-mode-enabled%3fhs_amp=true

Pieterjan
  • 2,738
  • 4
  • 28
  • 55
0

Yes, if you have debug mode enabled, any sort of data relating to an error can be displayed. This certainly would include sensitive data that would be useful when debugging.

For production, you want all errors to be privately logged, not publicly displayed. For this reason, you will want debug=false in your .env file.

If this is happening while debug mode is already set to false, you will want to configure the hiding/logging of errors at the server level.

Citizen
  • 12,430
  • 26
  • 76
  • 117