Verifiedapp Blog
Exposed Files

Your .git folder is public — and that is a full source-code download

· 2 min read
#exposed-files#git#source-code-leak

Why .git is so dangerous

The .git folder is the entire repository: every file, every version, every commit message, every author. Git keeps all of it locally so you can check out any past state. That is wonderful on your machine — and catastrophic on a public web server, because if /.git/ is reachable, an attacker can pull the whole thing down and rebuild your codebase as it exists and as it existed.

That history part is the sting. A secret you committed in a panic six months ago and removed the next day is still in the history. Remove it from the current files all you want — git remembers, and so does anyone who downloaded your .git.

How it gets exposed

The usual cause is deploying by copying the project directory — including its hidden .git folder — straight into the web root, then serving that folder without blocking dotfiles. Now requests like /.git/config and /.git/HEAD return real git data instead of a 404, and that is all an attacker needs to start.

How it is exploited

The attacker does not need your server to allow directory listing. Git's internal structure is predictable, so automated tools walk it file by file: read /.git/HEAD, follow it to the index and the object store, fetch each object, and reassemble the working tree. Within seconds they have your source. Then they grep the history for keys, passwords and tokens — the things that get committed by accident and are assumed gone.

How to tell if you are exposed

Request /.git/config or /.git/HEAD on your own site. If you get back text that looks like git internals — [core], repositoryformatversion, a ref like ref: refs/heads/main — your repository is downloadable. A 404 or a block is what you want to see.

How to close it

  • Do not deploy the .git folder. Build and ship only the artifacts you need, not the repository. A clean build pipeline never copies .git to production.
  • Block all dotfiles at the server. Deny any path starting with a dot, so a stray .git still cannot be read.
  • Rotate secrets if it was reachable. Assume anything ever committed — including in old, deleted history — is now known, and rotate it.
  • Scrub the history if needed. For genuinely sensitive commits, rewriting history removes them from the repository going forward, but treat already-exposed secrets as burned regardless.

Confirm it on your site

A public .git folder is invisible until someone requests the right path — so request it yourself. An automated scan checks /.git along with the other high-value leaked-file paths and tells you exactly what answers. Scan your site and make sure your source is not for download.

Related reading

FAQ

Can attackers really rebuild my code without directory listing enabled?
Yes. Git's layout is predictable, so tools reconstruct the repository by walking from /.git/HEAD through the object store, file by file. Disabling directory listing does not protect you — blocking the folder does.
I deleted a secret from my code. Is it still exposed via .git?
If the secret was ever committed, it lives in the history, and anyone who downloaded your .git has it regardless of your current files. Rotate the secret and treat it as compromised.
How do I deploy without exposing .git?
Deploy build artifacts, not the repository. Your pipeline should copy only the files the site needs to run, never the .git folder, and your server should block dotfile paths as a safety net.

Keep reading