Security Issue No1 Suggestion: Masking by default the information that resides in .env file!

In production, you remove the APP_ENV=local and APP_DEBUG=true statements from your .env file. Then your errors are not displayed in detail

@klodj Environment variables are only dumped in the error page if APP_DEBUG=true is set in your .env / environment variables.

If this is enabled on a production server, immediately disable it and change your keys and secrets. You need to assume a malicious third party has already seen them.

This is a misconfiguration problem and not a “security issue” with Laravel.

I know very well what to do but I was suggesting something else... I'm refering to the solution of masking the variables to be set as default!

https://stackoverflow.com/questions/46407009/how-to-hide-env-passwords-in-laravel-whoops-output/46407010

Why Laravel does not making it with stars by default!?

It's like leaving it unsecured purposely because you know that sometime for small and maybe insensitive projects the developer may not give importance to security but LARAVEL SHOULD!

Why Laravel does not making it with stars by default!?

@klodj Because environment variables are just key–value pairs at the end of the day, and it doesn’t know which ones are supposed to be sensitive and not.

@martinbean I hope you understand the importance of this issue! I'm sure that a solution can be found!

Maybe what you call just key-value pairs can be removed from that exposure and put in a more secure way. For example the KEY for DB name and the KEY for db password must be LIKE A CONSTANT or UNCHANGABLE / DEFAULT... whatever

You risk your reputation seriously!

... @klodj there is no reputation at risk here.

I did saw a time ago a laravel package that encrypted API_KEYS though in the .env file. But I am not able to find it anymore.

For example the KEY for DB name and the KEY for db password must be LIKE A CONSTANT or UNCHANGABLE / DEFAULT... whatever

And where do you want to store the constant?

I think this is the end of the disscusion but I insist that some default security precaution should be set!

Just in case the developer forgets it because you know we are humans... :)

Anyway great framework and many thanks for your replies

@klodj Of course I understand the issue. I’ve worked in web and software development for over 10 years now. But in that time I’ve also learned not to deploy websites and software with debug flags enabled that leak sensitive data such as environment variables.

I’ve worked on many projects—both as an employee and as a contractor; have contributed to various open source projects (including Laravel); written a book; edited another; in the top 2% of all Stack Overflow users; the top ten here on Laracasts… so I think I’ve built a pretty good reputation so far.

I think this is the end of the disscusion but I insist that some default security precaution should be set!

lol, ok... you insist. That is not how things work on the webs.

If you insist on changes to the code of Laravel this ain't the place to be. You should create a pull request or a ticket on the github pages of Laravel.

APP_ENV=production
APP_DEBUG=false

Is that so hard to do on your production server? Problem solved... No altering anything except the .env file, which is the whole point of the .env file...

Just in case the developer forgets it because you know we are humans... :)

This is why we write down procedures for deploying, and why there are things like deployment scripts to automate the process. I'd say if the developer forgets and their reputation "gets harmed", that tells you a lot about the developer and I wouldn't hire them since they are too lax in their basic security knowledge. If they mess something as simple as this up, why would I trust them with credit card or customer data? And maybe that developer needs to learn that lesson. I'd bet they'd pay more attention to security in the future.

That's like blaiming Messi for today's match! Or Ronaldo when he looses a penalty!

Guys, the answer I was expecting since the beginning of the disscusion would be smth like "...you are using an old version of laravel..." and I'm sure in the future it will be fixed... I promise to do it myself if necessary!

You are loosing precious time even in other disscusions I've seen in similiar situation and I don't want to offend but it is really stupid to show sensitive information that doesn't contribute to nothing in fixing any exception!!!

I said the disscusion is closed but I feel like I'll continue until a solution will be provided by laravel, because I really enjoyed programming with it but it's a disapointment that doesn't let you touching a single line of code... you know what I mean... and I'm doing this for my friend who had to make his first project and forgot that boolean shit

That's like blaiming Messi for today's match! Or Ronaldo when he looses a penalty!

Not really the same thing, unless Messi or Ronaldo were neglectful in being a professional fighter and just sat there or something and let the other guy knock him out. Or they stayed up too late partying the night before the match and couldn't concentrate.

I said the disscusion is closed but I feel like I'll continue until a solution will be provided by laravel

It won't be fixed, because it's how it's supposed to be, and is the whole point of the .env library that laravel uses.

@klodj You are just embarrassing yourself further

You are expected to read the documentation, and if there is anything you don't understand, you can ask here

https://laravel.com/docs/5.6/errors#configuration

You can just hard code the config, i.e., database in database.php. But you still need to have main laravel above

htdocs (public_html, www).

Future will tell

Future will tell

Yep, but seeing as how it's been this way for over 5 years now, and your post is the very first post I've seen asking for this type of thing, I tend to doubt it will be "fixed". It's how it is supposed to be. So, just don't hold your breath for it to change. It really won't. Learn your tools. It's not anyone's fault if you didn't do something, except yours, and now you want something else to protect you from your own negligence.

@klodj... I hope you are trolling here. Your argumentation makes no sense at all.

It's not my fault you don't understand what I'm saying. If you talk about arguments just give me a reason why exposing db password?! Why the hell is it showing in exception?!! Just answer me that!!!

Because you have debug=true, so it's showing you all of the values so you can, you know, debug things. debug=false, doesn't show any such details. Yes, I understand the issue. It seems you don't understand what the different settings are for, and got burned because you didn't do your homework.

When debug=false, all it shows is "whoops, something went wrong" or something very similar. Hardly a security concern.

.... because you are running your application in debug mode. That is why. No other explanation required.

But as you said earlier, we are done here because we do not understand eachother.

Ok here is an anecdode :) Some football team fans where distroying the cars of the oponent team fans, and a journalist asked... "why do you destroy the cars?" And they respoded "because they are of the other team fans" Ok, said the journalist, but why the cars? The response again "My friend you don't understand... they are of the other team's fans" The question keep being the same and the response also...

Anyway I feel like I'm in the wrong place, I don't know if you have to do with what I'm requesting.

Can you tell me who to contact for this issue?! Thanks

Can you tell me who to contact for this issue?! Thanks

Sure, in the github repo, but you'll only embarrass yourself with this. https://github.com/laravel/framework/issues

Embarasment is the enemy of the curation ;)

I have done java technology about 14 years and php about 15 years now. I have had errors. But I have never had that problem in production. In DEV you want and need the errors to fix code.

However I know what you are referring to, to star out things like passwords. I admit it would be nice.

The older SMVC framework did that for passwords only.

Seriously, put in a pull request to obscure certain things, and let Taylor and others have a look. Usually these improvements come from users like yourself.

A PR is the correct place for this, not the forum IMO.

It is already possible btw, see https://github.com/laravel/framework/pull/21336 since v5.5. The strange thing is that this is not in the documentation: https://www.google.com/search?q=site%3Alaravel.com+%22debug_blacklist%22

add this to 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',
        ],
    ]

The SO article covers it good, https://stackoverflow.com/questions/46407009/how-to-hide-env-passwords-in-laravel-whoops-output/46407010#46407010

So there @klodj

Done deal.

Thanks @click for the reference. There are newbees who go production and forget to turn debug off, etc.

@jlrdw yes but with that in mind the "newbees" also have no clue that they can even blacklist this. So if the goal is to prevent accidental leaks of passwords it would indeed be better to set this as a default as also suggested in the pull request.

Now that I see this solution and think about the usage I would agree with @klodj and the other github and SO posters to make this a default setting instead of optional non documented feature. At least to prevent the accidental password leaks.

So yes +1 for of making this a default.

Or at least draw attention in big font in docs the proper settings for production vs Dev.

But I agree, default would be better. A tired experienced developer could skip a setting, we are all human.

Of course @Cronix would never miss a setting, hehe.

But if you are allowing an application to go into production with debug=true, who knows what secrets you might be disclosing.

Its certainly more of an issue that people think its ok to just put the whole application into the public web space.

And then those that forget to change the blank database password or go into production with 'secret' as the password

At some point, you have to demand a level of professionalism - otherwise you just expect your site to be hacked.

To use the OP's football analogy, I would not hire a blind goalkeeper any more than a programmer that did not know the basics.

Every time I see this issue being brought up I remember when I was just starting out with laravel and spent about an hour trying to figure out why my new site wasn't working, until I actually looked at the error page and saw that I had a typo in my database password.

If environment variables were hidden by default, I don't know how long it would have taken me to find that typo.