helhum/dotenv-connector

security risk: .env file in public folder

Closed this issue · 1 comments

This extension expects the.env file in the public folder by default (root folder of the web server). That's a very high security risk or even break. As a default this file should be expected somewhere else outside the root folder.
The .env file will contains credentials that must be private and ran application should not rely on the server administration to exclude this file in the .htaccess or server configuration.

Thanks for creating this issue.

I agree that having a .env file exposed in a publicly accessible document root of a web server is pretty much a bad idea.

However this package does not make any assumptions in which context it is used.
It can be even be used for cli only applications or with any web application or web application framework, which all have different conventions where the document root is located.

The only assumption this package makes is that by default it looks for a .env file located in the same folder as the composer.json for this project.

This is a pretty secure default, because for security reasons it is also a pretty bad idea to expose this directory as document root. When doing so, the composer.json and composer.lock would be exposed, which would leak exact package names and even exact package versions being installed (information disclosure).
Even worse in this case is exposing the vendor folder publicly, which could introduce all sorts of security risks, as it could be that demo or test files are exposed of all installed packages. Such files more often than not are susceptible to XSS, SQLi or RCE.

Last but not least, the concept of .env files is rather meant for easy setup of dev environments than being meant to be run in production. You could run this in production, but then all security considerations from above should be taken into account, especially having the document root in a different folder than your application root folder.

I took all that for granted, but it might indeed be a good idea to add these to the readme.

Would you help out with a pull request to improve the readme in that regard?

Thanks