Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
Look, i can't help you see the reason this entire argument is pointless.
Suffice it to say that all security measures are flawed because they are implemented by human beings and have to be maintained by human beings.
What does hurt projects often [that i've experienced with at least half a dozen clients] is being overly paranoid and trying to secure everything to the point where basic assets are not accessible and sites go down when they shouldn't. At that point it's hurting more than it's helping. And having a .ENV file in 16 years has not once been the problem. So per my experience, it's not an issue. You claim otherwise, and as everything in this industry, we can leave it to personal preference.
I see you're really concerned, but you don't demonstrate anything. Why do you consider not using .env is being "overly paranoid"?
If you care about error 500 and other inconveniences, it happens a lot with .env, and many beginners have difficulties using them properly. Most of the time, teams use it because the framework forces them to use it, not as an internal methodology.
I don't know you, but it sounds like "I don't want to change my habits, I've been doing that for 16 years." If you're careful, which I assume you do, you might be ok with that approach, but that does not mean it's the best one.
Config files like that are primary targets that will be automatically scanned, and sadly, people tend to use the same credentials and API keys in all environments, sometimes making the attack even easier.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
500 errors only happen if you wrote bad code or didn't debug it enough. This is fact. I fully expect 500 errors if i forget to setup the correct configs in the .env file. You're supposed to fix those across your application and account for any combination of them and make sure to log them and keep an eye on those logs for new ones and then fixing them.
note, my habits extend 16 years, which means i've been coding since before env files existed and i still run some older monolith systems while also keeping up with various frameworks, platforms, services, tools and whatever else people keep coming up with. Config files only get scanned automatically if you don't secure the damn things which again shows that maybe you just lack experience in the field. Credential sharing happens yes, and it's just as bad as not securing your env file from external access, but so is clicking on a bad link in an email, or not setting folder permissions correctly, or a mountain of other issues. ENV files are not the problem, nor were they ever.
Discuss starts with "lol." If you think this is a battle, then win. Sorry to say that again, but you don't demonstrate anything. I've seen many uses of .env for convenience I did not find convenient or particularly efficient, but if I have to use them, then I use them.
Does not mean it's the best strategy out there. Does not mean you have to migrate all legacy projects right now because someone said you have to. Maybe think about other approaches for your next project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Look, i can't help you see the reason this entire argument is pointless.
Suffice it to say that all security measures are flawed because they are implemented by human beings and have to be maintained by human beings.
What does hurt projects often [that i've experienced with at least half a dozen clients] is being overly paranoid and trying to secure everything to the point where basic assets are not accessible and sites go down when they shouldn't. At that point it's hurting more than it's helping. And having a .ENV file in 16 years has not once been the problem. So per my experience, it's not an issue. You claim otherwise, and as everything in this industry, we can leave it to personal preference.
I see you're really concerned, but you don't demonstrate anything. Why do you consider not using .env is being "overly paranoid"?
If you care about error 500 and other inconveniences, it happens a lot with .env, and many beginners have difficulties using them properly. Most of the time, teams use it because the framework forces them to use it, not as an internal methodology.
I don't know you, but it sounds like "I don't want to change my habits, I've been doing that for 16 years." If you're careful, which I assume you do, you might be ok with that approach, but that does not mean it's the best one.
Config files like that are primary targets that will be automatically scanned, and sadly, people tend to use the same credentials and API keys in all environments, sometimes making the attack even easier.
lol
500 errors only happen if you wrote bad code or didn't debug it enough. This is fact. I fully expect 500 errors if i forget to setup the correct configs in the .env file. You're supposed to fix those across your application and account for any combination of them and make sure to log them and keep an eye on those logs for new ones and then fixing them.
note, my habits extend 16 years, which means i've been coding since before env files existed and i still run some older monolith systems while also keeping up with various frameworks, platforms, services, tools and whatever else people keep coming up with. Config files only get scanned automatically if you don't secure the damn things which again shows that maybe you just lack experience in the field. Credential sharing happens yes, and it's just as bad as not securing your env file from external access, but so is clicking on a bad link in an email, or not setting folder permissions correctly, or a mountain of other issues. ENV files are not the problem, nor were they ever.
Discuss starts with "lol." If you think this is a battle, then win. Sorry to say that again, but you don't demonstrate anything. I've seen many uses of
.envfor convenience I did not find convenient or particularly efficient, but if I have to use them, then I use them.Does not mean it's the best strategy out there. Does not mean you have to migrate all legacy projects right now because someone said you have to. Maybe think about other approaches for your next project.