Configuration files are everywhere. As developers, we use them to configure our computers but also in our projects.
There are many kinds of dotfiles and even files without extension, and most contain sensitive data such as credentials for database access or API Keys.
Who cares? They’d never know.
Security through obscurity is such a waste of time. You cannot cross your fingers and hope the bad guys will never find your not-so-secret files.
Tools such as gobuster allow anybody to browse your website and list directories and files.
It gets easier to locate specific configuration files such as the
.env file, and above all, it allows for automating the process.
If the file is web-accessible, then it’s the jackpot. Hackers only have to collect data and start injecting poison.
With API Keys or database credentials, the game is over. They win. You lose.
CMS constraints often lead to exposure
WordPress is the most popular CMS of all time.
However, everything is at the same level and publically accessible by default, so I see many WP installations containing configuration files mixed with core files, themes, and plugins.
There are ways to mitigate and even solve this issue, but it requires a little reorganizing, which takes some time.
In that perspective, I recommend using Bedrock, a secure architecture for WordPress that relies on Composer.
With Bedrock and similar organizing, the root folder is not the public folder. As a result, configuration files are not accessible from the web.
Check your server config
Whether you use Apache or Nginx, make sure no one can fetch your files.
As I mentioned above, it’s best if those files are not in the public folder, but you should at least forbid access with a 403 error if that’s the case.
If you use Apache, you can even do it at your developer’s level with a simple rule in the
<Files .env> order allow,deny Deny from all </Files>
Don’t think about nesting configuration files in subfolders as we saw there are free tools to list directories and files automatically.
Less critical but still dangerous files
Some files do not contain credentials or API keys, but that does not mean there is no disclosure.
If you use Composer, you should not deploy the
composer.json and the
composer.lock files in production. It’s quite the same for
Most of the time, if you don’t do strange things, there is no direct exploit, but it gives precious information about your vendors and your custom scripting.
Exclude it from the git tracking
Don’t neglect your git repository. With the wrong settings or in case of human mistakes, your might expose your credentials one way or another.
I’ve already seen excellent deploy configurations that clean all the sensitive data but with a git repository that still contains the creds in plain text.
Env vars are excellent, but because dealing with server config is not convenient for many developers, the
.env file has become popular. There are also handy parser libraries to work efficiently.
The point is not whether you should use it or not. Sometimes, even the framework itself relies on it.
The point is to exclude it from the git tracking, so you don’t ultimately deploy it along with your releases.
The best way to do it is to ignore the
.env files in your global config by editing the following file:
This way, even if you don’t correctly configure the
.gitignore file in your specific project, it’s globally ignored by git on your machine.
You should never add credentials or API keys to the git tracking.
dotenv files are handy for the developers, things can turn nasty when deploying on the live production server.
As those files usually have a standard format, they are easy targets for penetration tools.
It’s also best if you avoid any disclosure about your architecture, your vendors, or your maintenance process.