This Beyond Code package provides a convenient mechanism for encrypting and then accessing 'secret credentials' https://github.com/beyondcode/laravel-credentials. Essentially you move the secrets out of the env file.

However this doesn't prevent the issue of leaking sensitive or secret information from stacktraces - being able to view the debug output in production is essentially the primary issue (as everyone else has pointed out).

I don't remember who said that (some comments are edited or removed) but I totally agee if you say this is a free framework and maybe you have to pay for having all the wholes closed. I totally agree with that!

this is a free framework and maybe you have to pay for having all the wholes closed.

Yes, you, the developer, are being paid to make sure there are no proverbial holes in your app. In this case, all you have to do is not put them there in the first place.

I mean paid framework. Like when you buy Microsoft Windows it has firewall enabled by default.

It does have nothing to do with framework being paid or not. Responsibility for not allowing to leak sensitive data is on developer side. If you can't configure two environment variables on production maybe it's better idea to change profession and become graphic designer or so.

I agree with all of the statements that you should not deploy anything to a live environment unless you know what you are doing.

But the reality is different. There are people who are deploying applications to live environments. And IMO it could not harm anybody if the default settings would protect the unexperienced developers here.

So I would vote for "security first" settings to prevent all of these accidental leaks of credentials. Is there any reason not to do it?

Do you remember the 'MongoDB no password gate' from last year? MongoDB by default did not set a password and was not restricted to localhost connections only. So if the developer did not configure this the database was open for everybody. You saw a lot of comments like: "stupid developers, why didn't they do this and that". Yep, totally agree. But... it happened.

After these hacks they changed their default configuration:

Helping direct users towards safe network options is why since release 2.6.0 we have made localhost binding the default configuration in our most popular deployment package formats, RPM and deb. This means all networked connections to the database are denied unless explicitly configured by an administrator.

So by default their settings are now 'secure' and if you want to open up your database you have to configure that manually.

Sources

• https://www.bleepingcomputer.com/news/security/admin-accounts-with-no-passwords-at-the-heart-of-recent-mongodb-ransom-attacks/
• https://krebsonsecurity.com/2017/01/extortionists-wipe-thousands-of-databases-victims-who-pay-up-get-stiffed/#more-37597
• https://www.mongodb.com/blog/post/update-how-to-avoid-a-malicious-attack-that-ransoms-your-data

Why must we appeal to the lowest common denominator? Do you also insist that lego bricks be made soft so people don't hurt themselves when they step on them? Do you blame the nails when someone does a poor job of building a shed and someone pricks their finger on an exposed nail? Maybe hammers should come with built-in thumb detectors and airbags to prevent people from hitting their own fingers.

Laravel is as secure as you want it to be. If you're deploying an app to a production environment, you need to know how to set up your environment and protect your data. This is not optional.

The dotenv library isn't even meant for production environments, it's a development tool. If you rely on development tools to configure your production environment, you need to make yourself aware of what the associated risks are.

If you look at a variable named APP_DEBUG and set it to true when deploying to production, you should really consider a career change.

@36864 but what would be a reason to not set the default configurations to protect the developer?

The argumentation: "you should really consider a career change if you can't do this and that" is not a valid argument IMO. Not everybody is using Laravel on a professional level. Accept the fact that is happening. Why wouldn't we protect them with a simple default configuration? I think the pro's are bigger than the cons in this case.

Pros:

• Neglectful devs won't leak their passwords online

Cons:

• Additional steps to get full debug information during development
• Neglectful devs will continue to be sloppy and fail to properly set up their environments, possibly leading to severe problems down the road.

Feel free to complete the list.

I think one of the main problems is:

Laravel is so popular that people new to programming start with it.

Meaning they have no

• HTML
• PHP
• CSS
• Security Training

first. There are folks on the forum who's been learning laravel for a while who have no idea about the OWASP site. No idea what CSRF or XSS is.

Even the skilled trades such as an electrician has to go through an apprenticeship program, usually 4 years.

A good developer on their own studies topics to learn correctly, but many newbees plunge into laravel and think or act as if laravel was like a magic code generator that auto handles everything.

It's not, it's a php framework.

So I agree the developer should implement proper security, etc.

But a real developer is the ones who have learned correctly, not the ones who started with laravel and 3 weeks later call themselves developers.

@martinbean good for you and I admire your achievements, but I didn't start this conversation to to show mines, cause I also have been programming since qbasic and pascal. Here I took the courage to raise this issue as behalf of one of my students, who by the way thank you for your suggestion @Yorki one career in programming is over after risking to go to jail at his first project... a password is like loosing the keys of the house!

@Cronix you are lucky man, I bet you work in a team where nothing is left unchecked and have a 'replica' in case you fail, but I doubt you have been in a project where everything is expected only from you, everything... servers, networking, db, programming, maintenance and so on!!!

@Snapey I didn't find that in the documentation but in stackoverflow, and what I'm asking or suggesting is nothing else than making it default (like windows firewall).

@jlrdw and @click thanks for your endorsements, if somebody else want this fixed just don't be afraid to give a thumbs up. There is nothing to be embarrassed - I'm with Messi even after loosing the penalty! Look at his team they are all losers and they have the courage to blame him.

@36864 oh you had a typo in your password - copy/pasted I guess - anyway you really made me laugh thank you

you are lucky man, I bet you work in a team where nothing is left unchecked and have a 'replica' in case you fail, but I doubt you have been in a project where everything is expected only from you, everything... servers, networking, db, programming, maintenance and so on!!!

I did that for 12 years as an independent contractor when I started my company. I've built some very large, high traffic, multi-million dollar sites that are still running and generating a lot of revenue ;) And most of these automated tools and frameworks we have today to do this stuff for you didn't exist. So you really actually had to know things. But thanks for assuming. ;)

@Cronix the problem is as simple as the solution, can you endorse me on this? After this feature was added to Laravel the guy who created it stated very well that this needs to be default. You can check it if you want in github.

bored

Should laravel build the server for people too, to protect them from their own lack of knowledge? I see way to many people improperly set up their servers, especially shared hosting, and you can access .env directly and see all of the raw credentials.

Like this guy who I told about it 2 days ago and still hasn't fixed it: http://admin.creativehedgehog.co.uk/.env

That's different case! I guess he just needs an .htacces s file. By the way Laravel could provide that too :p (just kidding)

Well if all laravel uses had to go through a four year apprenticeship program like an electrician and have to legally be a jouneyman programmer first that would more than solve the problem, there case closed.

Even carpentry has a four year apprenticeship program, so does brick and block Masons, sheet metal mechanics Etc.

Thankfully aircraft mechanics have to go through a lot of training and pass test.

So newbies learn some stuff first geez.

And like @Cronix said

Like this guy who I told about it 2 days ago and still hasn't fixed it:

I can't really have sympathy for someone who is warned about security and doesn't even bother fixing it. But I am concerned about the Developers poor users who's private data might be at risk.

Accidents happens, conseguences cannot be reversed.

Hi @klodj

I assume that just by reading these replies, by now you've already concluded that the community around this small framework is very toxic. There have already been a lot of developers telling not to print credentials on webpages/api responses, but each call results in the same discussion, and wannabe framework developers trying to defend their "ideals".

In the end, many companies aren't interested in using this framework just because of this behavior, and the responses triggered when someone starts talking aboit this issue.

I myself only used laravel for about a week while developing my website, until I noticed my database credentials on the debug page. I immediately switched to ASP.NET Core ever since.

@jimknibble sounds like you are no position to comment on this community.

I wonder why you are here tbh ?

Oh, and thanks for dragging up a pointless discussion after year

You're talking shit. phpdotenv is a production dependency: https://github.com/laravel/framework/blob/7.x/composer.json

who's toxic ?

I can't really have sympathy for someone who is warned about security and doesn't even bother fixing it

My god, what an irony. The statements in this discussion are really amazing!!

Maybe wannabe framework developers should go through a apprenticeship program of 4 years before they can just start writing an MVC framework. That would more than solve the problem...

Hi guys, what happened with this? Sorry the company switched to Node js and Typescript but I'm just curious what's happened after 4 years? :)