Is Your Website Leaking Sensitive Files? The .env, .git and Backup-File Problem
Of all the ways a business website gets compromised, this one is the most avoidable and the most common — a configuration or backup file, never meant to be public, sitting quietly at a predictable URL that anyone can request directly. No exploit, no password guessing, no sophisticated attack required. Just a file that shouldn't be there, and a request to fetch it.
The .env File
Popular in modern PHP and JavaScript frameworks, a .env file typically holds database credentials, API keys, and other secrets in plain text, meant to be read only by the application itself. If the web server is misconfigured to serve it as a plain text file instead of blocking access, anyone who requests yoursite.com/.env directly gets those credentials handed to them.
The .git Folder
If a site was deployed by copying an entire Git repository onto the server — including its hidden .git folder — the site's complete version history becomes publicly fetchable, often including old code with hardcoded credentials that were removed from later versions but never scrubbed from history.
Backup Files Left in the Web Root
A developer makes a quick edit, saves a backup copy as wp-config.php.bak or config.php.old "just in case," and forgets to delete it. Because web servers often serve unrecognized file extensions as plain text rather than executing them, that backup — credentials and all — becomes directly readable by anyone who guesses the filename, and these filenames are guessed by automated scanners constantly.
Why This Keeps Happening
These files aren't exposed because of some novel attack technique — they're exposed because deployment processes copy more than they should, and nobody checks what's actually reachable from the outside afterward. A file being present on the server isn't the problem; a file being present and publicly fetchable over HTTP is.
Check Your Own Site Right Now
Our free Website Security Checker specifically probes for commonly-exposed sensitive files like these — .env, .git/config, backup files and more — comparing the response against your site's actual "not found" behavior to avoid false alarms, and flags anything that shouldn't be publicly reachable.
Fixing It Properly
The fix itself is usually simple — a web server rule blocking access to dotfiles and backup extensions, and removing what shouldn't be there in the first place. The harder part is knowing to check at all. Decoding IT's website security audits include exactly this kind of exposure check as standard, not an afterthought.
Decoding IT is a Muscat-based IT solutions provider helping businesses across Oman find and close these gaps before someone else finds them first. Contact our team for a website security audit.
- Log in to post comments