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).
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.
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.
Feel free to complete the list.
I think one of the main problems is:
Meaning they have no
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.
So I agree the developer should implement proper security, etc.
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. ;)
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