Exposed .git and .env files: how they go public and how to check

A deployment that copies the whole project folder can publish your source code and your secrets next to your homepage. It takes a minute to check and a little longer to fix properly.

Offensly Team··2 min read

Some of the most damaging findings in a web test are not vulnerabilities in code at all. They are files that should never have been deployed: a .git folder, a .env file with database passwords, or a backup.zip of the whole site.

How it happens

  • The whole working copy is deployed. Copying the project folder to the server with FTP, rsync or a container COPY . . takes the hidden files along.
  • The server serves dotfiles. Many web servers return any file under the document root, hidden or not, unless told otherwise.
  • Backups land in the web root. A quick site-old.zip or dump.sql before an upgrade stays there for years.

With a readable .git folder, anyone can download the repository history, including files you deleted later and secrets that were committed once. A readable .env hands over API keys and database credentials directly.

For the business

This is a data leak that needs no hacking skills: the files are fetched like any other page, and automated scanners look for them constantly. If secrets were exposed, assume they were copied. The fix is cheap; the cleanup after a leak is not.

Check your own site

These requests should return 404 or 403, never the file:

curl -sI https://example.com/.git/HEAD
curl -sI https://example.com/.env
curl -sI https://example.com/.DS_Store

Only run checks like these against sites you own or are allowed to test.

Fix it properly

  1. Deploy build output, not the repository. Publish only the folder your build produces, so source and config never reach the web root.
  2. Refuse hidden files at the server. Add a rule that returns 404 for any path segment starting with a dot, except /.well-known/.
  3. Keep backups out of the web root, and delete the old ones.
  4. If anything was exposed, rotate it. Change every password and key that was in the file or in the repository history, then check your logs for their use.

How Offensly tests it

The Offensly penetration test looks for exposed files together with open ports, TLS, security headers and known vulnerabilities. It runs only after you verify that the website is yours, and you get the exact URLs it found, with how to fix each one.

See how penetration testing works

Check your own domain in seconds

The free check reads your SPF, DKIM, DMARC and MX records and tells you exactly what to fix. No sign-up.