Dr.Who
← blog

A publicly served .git or .env folder is a serious leak — one rebuilds your source, the other hands over secrets

· git · dotfiles · secrets · web-security · attack-surface

gitdotfilessecretsweb-securityattack-surface

Yes — a publicly served /.git/ directory or /.env file is a real and frequently exploited exposure. A reachable .git directory lets anyone reconstruct your entire source code, including history and any secrets ever committed, because the directory contains everything needed to rebuild the repository. A served .env file leaks credentials directly — database passwords, API keys, signing secrets — in plain text to whoever requests it. Both happen when the web root accidentally includes files that were never meant to be web-accessible, and both are trivial to find with automated scanners.

How an exposed .git is exploited

The .git directory is a self-contained database of your repository. If the web server serves it as static files, an attacker walks it programmatically. Tools like git-dumper start from the predictable paths and reconstruct the working tree:

/.git/config
/.git/HEAD
/.git/index
/.git/refs/heads/main
/.git/logs/HEAD
/.git/objects/...

From HEAD and refs they find the latest commit; from the objects store (loose and packed) they pull every blob and tree; from logs/HEAD they recover history even when directory listing is disabled. The result is your complete source — config files, internal endpoints, validation logic, and any password, token, or key that was ever committed, even if you later deleted it, because git history keeps it. Source disclosure alone is dangerous; recovered secrets turn it into account takeover.

How an exposed .env is exploited

A .env file needs no reconstruction at all. A single request returns the contents:

DATABASE_URL=postgres://user:password@host:5432/app
STRIPE_SECRET_KEY=sk_live_...
JWT_SECRET=...

Anyone who fetches https://example.com/.env gets live credentials. Scanners probe this path constantly, so an exposed .env is usually found within hours of going live. The blast radius is whatever those secrets unlock: your database, payment processor, mail provider, or cloud account.

How to fix and prevent it

The exposure is a deployment and configuration problem, fixable at several layers:

  • Block dotfiles at the web server or CDN. Deny any request whose path contains /.git, /.env, or a leading-dot segment, returning 404 or 403. Do this at the edge so it applies regardless of what is on disk.
  • Never deploy the .git directory. Build artifacts and deployments should not include version-control metadata; exclude .git from the image, archive, or upload step. A web root should contain only what the site needs to serve.
  • Keep secrets out of the web root entirely. Load configuration from environment variables or a secrets manager, not from a file sitting alongside served content. If a .env must exist on the host, place it outside any directory the web server maps to a URL.
  • Rotate anything that leaked. If a .git or .env was ever reachable, assume the secrets are compromised and rotate them — removing the file does not un-leak what was already fetched or indexed.

The practical first step is to find out what is actually reachable. Probe your own origin for /.git/config, /.git/HEAD, and /.env, or run the web surface inspector to see which sensitive paths respond.

Check what's reachable on your site →

Further reading