Introduction

A publicly accessible .git directory can expose far more than the current site files. Repository history, deleted code, configuration fragments, and accidentally committed secrets may all become recoverable if the .git path is reachable over HTTP. The fix is to block access immediately and assume anything stored in the repository may need review and rotation.

Symptoms

  • Requests to .git/ paths return data instead of a denied response
  • Security scanners report the site's repository metadata is exposed
  • The server hosts a deployed working copy instead of a clean build artifact
  • The repository may contain config files, secrets, or historical code that should not be public
  • You cannot confirm whether the exposed repository was downloaded by unknown parties

Common Causes

  • The site was deployed directly from a Git working tree inside the web root
  • Web server rules do not block access to dot-directories
  • A migration or manual deploy copied the repository metadata into the public path
  • Hardening focused on application routes but not underlying filesystem exposure
  • Temporary staging or debug environments were promoted to production without cleanup

Step-by-Step Fix

  1. Block access to the .git path immediately at the web server, CDN, or platform edge.
  2. Remove repository metadata from the public serving path or redeploy using build artifacts that exclude VCS data.
  3. Review the repository for secrets, config files, and sensitive historical content that may have been exposed.
  4. Rotate any credentials, keys, or tokens that appear anywhere in the repository history or config.
  5. Inspect access logs and scanner traffic to estimate whether the .git directory was requested or harvested.
  6. Check the live application for related exposures such as .env files, backup archives, or debug endpoints.
  7. Re-test the .git paths publicly and confirm they now return denied or missing responses.
  8. Review deployment workflows so repositories are never served directly from the web root again.
  9. Treat the incident as broader than a single directory listing, because repository history can reveal more than the current codebase.