ShipGuardScan a site

Exposed .git Directory on Production: Fix Guide

Updated 2026-10-17

If /.git/config or /.git/HEAD is downloadable, tools can usually reconstruct your repository object by object — including old commits with secrets you thought you deleted.

Confirm

A real exposure returns [core] and repositoryformatversion from /.git/config, or ref: refs/heads/... from /.git/HEAD — not your HTML homepage.

Fix

Deploy only build artifacts, deny /.git at the server/CDN, and redeploy. Then search your history for committed secrets and rotate them.

# search history for common key prefixes
git log -p --all | grep -nE "sk_live_|sk-proj-|sk-ant-|service_role|re_[A-Za-z0-9]{6,}_" | head

Checklist

  • /.git/* returns 404
  • Deploy publishes build output only
  • History scanned for secrets
  • Found secrets rotated

Copy-paste fix prompt

My deployed site exposes /.git. Change the deployment so only the build output is published, add a deny rule for /.git and other dotfiles, and write a script to scan my git history for common API key prefixes.

FAQ

Is a private GitHub repo enough protection?

No. The exposure is on your web server, independent of where the repo is hosted.

Do I need to rewrite history?

Rotating leaked secrets is what matters. Rewriting history is optional cleanup and does not un-leak anything.

Check your deployed app in ~25 seconds

Free passive scan: leaked keys, Supabase exposure, public config files and headers.

Run a free scan

Related