Most web developers use Git to manage their code. It keeps a complete history of every change ever made and makes deployment straightforward. But when code is deployed to a web server, the .git folder often comes along for the ride — and if that folder is accessible via the web, anyone can download your entire source code, including every secret the application has ever contained.

What Is a .git Directory?

When you initialise a Git repository, it creates a hidden folder called .git in the root of your project. This folder contains:

  • The complete history of every file ever committed, including deleted files and previous versions
  • Configuration files that may contain repository URLs, author information, and sometimes credentials
  • Every version of your source code files
  • Commit messages describing exactly what each change does

For a developer, this is invaluable. For someone who should not have it, it is a complete map of your application.

How Does a .git Directory End Up Public?

When a developer deploys their application to a web server, they often copy or sync the entire project directory — including the .git folder — to the server’s web root. If the web server serves all files in that directory (common on basic shared hosting), the .git folder becomes publicly accessible.

A request to https://yourwebsite.co.uk/.git/config might return a readable configuration file. From there, automated tools can reconstruct the entire repository by downloading individual object files and reassembling them. Tools like git-dumper automate this process entirely.

What Can an Attacker Do With Your Source Code?

Hardcoded credentials. Developers sometimes commit secrets directly into code — database passwords, API keys, AWS credentials — intending to clean them up later and forgetting. Git never forgets. Even if you deleted those credentials in a later commit, the original commit is still in the history and completely recoverable.

Business logic vulnerabilities. With your source code, an attacker can study your application’s logic and find vulnerabilities that would take much longer to discover through blind testing — SQL injection points, authentication bypasses, and insecure direct object references.

Proprietary code exposure. For businesses whose software is a product or a competitive advantage, source code exposure is a significant intellectual property loss.

Infrastructure reconnaissance. Code often reveals server paths, internal hostnames, third-party service names, and other details that help attackers plan further attacks.

How Common Is This?

In 2017, security researchers found thousands of websites — including government sites, financial institutions, and e-commerce platforms — had exposed .git directories. Live database credentials, API keys, and sensitive configuration data were found in repositories belonging to major organisations.

The Shodan and Censys search engines can be used to find web servers exposing .git directories at scale. Automated bots continuously scan the internet for these exposures. This risk is closely related to the exposed .env file problem — both involve developer files reaching the public web that should never be served.

How to Check

Visit https://yourwebsite.co.uk/.git/config in your browser. If you see a Git configuration file with content like [core] or [remote "origin"], your Git repository is exposed. If you see a 403 Forbidden or 404 Not Found, you are protected from this particular attack.

What to Do Next

  • Block access immediately. In Nginx: location ~ /\.git { deny all; }. In Apache .htaccess: use a <Directory ".git"> block to deny all access.
  • Deploy without the .git directory. Rather than syncing your entire project to the server, deploy only the built files that need to be publicly served. Use CI/CD pipelines (GitHub Actions, GitLab CI, Netlify) that handle deployment properly and never place the .git directory in the web root.
  • Move the web root. Configure your web server so the publicly served directory is a subdirectory (e.g., /public or /web). The .git folder stays above the web root and is never publicly accessible.
  • Rotate any exposed credentials. If your .git directory has been accessible for any length of time, treat any credentials ever committed to that repository as compromised. Rotate all database passwords, regenerate all API keys, and change all hardcoded secrets.
  • Review your commit history for credentials that should never have been committed — even in old, long-deleted commits.

Even if you see no signs of compromise, acting on the assumption of exposure is the only safe approach.

W3IT’s free security check tests whether your .git directory is publicly accessible as part of a comprehensive scan of your website. Run it now to find out before an attacker does.