The Danger of Exposed .env and Config Files on Your Website

A single misplaced file, sitting quietly in a public folder, has been the actual root cause behind more breaches I have looked into than any clever exploit ever was. It is rarely dramatic. It is usually just a config file that should never have been reachable by a browser at all.

A single readable config file can hand over database credentials, API keys, and secret tokens all at once.

In this post

1. What actually lives inside these files
2. How they end up publicly accessible in the first place
3. How attackers find them, at scale, without even trying hard
4. A quick, safe check you can run right now
5. How to actually fix and prevent this

Environment files, typically named .env, and other configuration files hold the sensitive settings a web application needs to run: database credentials, API keys, secret tokens used to sign sessions, and sometimes third-party service credentials for payment processors or email providers. They are meant to live outside the reach of a normal visitor entirely. When they do not, the consequences can range from embarrassing to catastrophic, and the mistake that causes it is almost always something small and avoidable.

What actually lives inside these files

A typical .env file might contain something like this:

DB_PASSWORD=hunter2example
MAIL_API_KEY=sk_live_abc123
STRIPE_SECRET_KEY=sk_live_xyz789
SESSION_SECRET=a1b2c3d4e5f6

Every one of these values, if read by someone other than the application itself, hands over real, usable access. A database password can expose or let someone modify your entire site's data. A payment processor's secret key can allow fraudulent transactions or expose customer payment data. A session secret can let an attacker forge valid login sessions for any user on the site, including administrators, without ever needing to guess a single password.

How they end up publicly accessible in the first place

• Default web server configuration gaps. Many web servers will happily serve any file in the web root directory unless specifically told not to, and a config file placed in or near that public directory becomes reachable by simply typing its filename into a browser.
• Framework misconfiguration in production. Some frameworks include debug or development modes that expose configuration details through error pages, left accidentally enabled after the site goes live.
• Backup files left in place. A quick manual backup, config.php.bak or .env.old, created during maintenance and never removed, often is not covered by the same access rules protecting the original file.
• Version control folders deployed to production. An exposed .git folder can, in the worst cases, let someone reconstruct a site's entire commit history, including any secrets that were ever committed, even ones later removed from the current code.

How attackers find them, at scale, without even trying hard

This is the part that surprises people most. Nobody needs to specifically target your site to find this. Automated scanners constantly crawl huge swaths of the internet, systematically requesting known filenames like .env, config.php.bak, and .git/config against millions of domains, simply checking which ones respond with real content instead of a 404 error. Being a small, low-traffic site offers no protection here at all, since the scanning is indiscriminate and automated, not aimed at specific targets.

A quick, safe check you can run right now

You can check your own site the same harmless way a scanner would, by typing a few common paths directly into your browser's address bar, replacing the example domain with your own:

https://yoursite.com/.env
https://yoursite.com/.git/config
https://yoursite.com/config.php.bak
https://yoursite.com/wp-config.php.bak

If any of these returns actual file content instead of a 404 or 403 error, that file is publicly exposed and needs to be addressed immediately. This is checking your own property, the same way you would check whether your own front door is locked, and is a reasonable, safe thing to verify on any site you own or manage.

How to actually fix and prevent this

1. If you find an exposed file, remove or relocate it immediately, then rotate every credential it contained, database passwords, API keys, session secrets, since simply removing the file does not undo any access that already happened
2. Store .env and similar config files outside your web server's public root directory entirely wherever your hosting setup allows it, so there is no URL path that can reach them at all
3. Add explicit server rules denying access to dotfiles and common config file patterns, most web servers support this through a configuration block that blocks any request for files starting with a dot or ending in .bak, .old, or .sql
4. Never deploy a .git folder to a production web server, and check now whether yours is exposed using the method above
5. Add a .gitignore entry for your .env file from the very start of a project, so it never gets committed to version control in the first place, where it could later leak even after being deleted from the live site
6. Consider running a secret-scanning tool like Gitleaks against your own repository periodically, to catch a credential that made it into commit history before you noticed

Why this one bothers me more than flashier vulnerabilities: this is not a sophisticated attack. It requires no skill from the person exploiting it, just an automated scanner and a list of common filenames. That is exactly why it keeps happening, and exactly why the five-minute check above is worth doing on any site you are responsible for, today, not as a someday task.

None of this requires advanced technical knowledge to fix, it requires knowing this specific, boring, entirely preventable mistake exists and checking for it deliberately. Given how quietly severe the consequences can be, and how little effort the check itself takes, it belongs near the top of any small site owner's security checklist, not buried somewhere near the bottom.