A handful of file paths — left behind by accident, not by design — can hand over your entire codebase, database, or credentials to anyone who knows to look.
A .git folder is version control — the complete history of every change ever made to a codebase, including anything that was added and later removed but never actually purged from history. A .env file is where most modern applications store their secrets: database passwords, API keys, third-party service credentials. A database backup (backup.sql, dump.sql) is, plainly, a copy of the database itself. None of these are meant to be reachable from a web browser — they're meant to sit outside the folder a web server actually serves.
This is almost never a deliberate choice. It usually happens when a deploy process copies an entire project directory — including its hidden .git folder and any local .env file — straight into the web server's public root, instead of deploying only a built, production-ready output. A backup taken "just in case" and left in the same folder as the live site has the same effect. The result is a URL like yoursite.com/.git/config or yoursite.com/.env that quietly returns the file's contents to anyone who requests it.
The scan requests a fixed list of the most common paths where this mistake shows up — .git/config, .git/HEAD, .env, .env.local, common backup filenames, a WordPress config backup, and .htpasswd — and, for anything that responds, checks that the content actually looks like the real thing (a git config block, real environment-variable syntax, SQL statements) rather than just trusting a "200 OK" status, which some servers return for pages that don't really exist. A first request to a random, definitely-nonexistent path establishes what your server's real "not found" response looks like, so a soft-404 page doesn't get mistaken for a genuine file.
Remove the file or folder from whatever directory your web server actually serves — for .git, that means excluding it from the deploy entirely, not just from your build output; for .env and backups, moving them outside the public webroot (or, for .env, using your host's environment-variable settings instead of a file at all). Because these findings mean the contents were genuinely downloadable, the fix isn't complete until every credential that could have appeared in them — database passwords, API keys, anything in git history — has actually been rotated, not just hidden.
This is consistently one of the most severe things an external scan can find, because it's rarely partial — an exposed .env or database backup is often the entire set of keys to the business's systems, not a hint that something might be wrong. It's also one of the cheapest to fix once found: no code changes, just removing files that should never have been public and rotating what they exposed.
Want to know where your own domain stands? CBWatch checks this — and eight other categories — in about ten seconds, free, no signup.
Run a free scan →Want CBWatch to catch this automatically going forward? See what monitoring includes →