securityaudit.website
Fix guide

Is Your .git Folder Exposed? How to Find and Fix It

Deploying by running git pull on the server is convenient — and it's also how thousands of sites accidentally publish their entire source code. If your audit flagged an exposed .git folder, treat it as urgent.

Why it's dangerous

When the .git directory sits inside your web root and the server happily serves its files, anyone can request /.git/HEAD, /.git/config, and the object files. From those, tools can reconstruct your full repository — including commit history. That history routinely contains things people thought they'd removed: old API keys, database passwords, internal hostnames, and the complete logic of your application.

How to check

The quickest manual test is to request the HEAD file:

https://yourdomain.com/.git/HEAD

If you get back something like ref: refs/heads/main, the directory is exposed. A 404 or 403 is what you want to see. (Our scanner does exactly this check as part of every audit.)

How to fix it

Best fix: don't deploy the .git directory at all. Build artifacts on a CI runner and ship only the files the app needs. The repository metadata has no business being on a production web server.

If you must deploy with Git, block access to the directory at the web server:

# nginx
location ~ /\.git { deny all; return 404; }
# Apache
<DirectoryMatch "^/.*\.git/">
  Require all denied
</DirectoryMatch>

The same idea applies to other dot-directories and metadata: .svn, .hg, .env, .DS_Store. Deny the lot.

After you fix it

Blocking access stops the leak going forward, but assume anything that was exposed is already compromised. If your history contained secrets:

  1. Rotate every credential that appeared in the repo — API keys, DB passwords, tokens.
  2. Don't just delete the secret in a new commit; it's still in history. Rotate the actual secret.
  3. Review access logs for requests to /.git/ to gauge whether anyone pulled it.

Verify

Re-run the audit. The .git check should report as not exposed. While you're at it, consider publishing a security.txt so researchers have a clear way to report anything else they find.

Want to know if your site has this issue?
Run a free audit →

More guides