Home › Blog › Hardening · Case study

An Exposed .git Folder Gives Away Your Whole Site. Check Yours.

A publicly readable .git folder can hand over the entire source of a site in seconds. The same misconfiguration affected the rest of the portfolio.

Why the .git folder is a treasure trove

The .git directory stores every commit, every branch, and every file that ever existed in the project. When an attacker can retrieve that data, they can reconstruct the full codebase, including versions that were deliberately removed because they contained sensitive information. Even if the current live version looks clean, older snapshots may still hold API keys, passwords, or internal logic that was never meant to be public.

Beyond secrets, the full history reveals development patterns, third‑party libraries, and configuration details that help an adversary understand the application’s attack surface. Rebuilding the exact state of the site at any point in time makes it easier to craft targeted exploits, especially when the code includes legacy endpoints or debug utilities that were later disabled.

How the exposure slipped past automated scans

In the first‑party case, a scan that used hundreds of templates reported a clean bill of health, yet a simple manual request to /.git/HEAD returned readable content.

Manual reconnaissance, such as typing the path into a browser or using a basic curl command, can reveal the problem instantly. The key is that the web server was not instructed to reject paths that begin with a dot, so the default file‑serving behavior exposed the repository. This highlights the importance of complementing automated checks with a quick manual verification step.

A quick test you can run on any site you own

Open a browser and add /.git/HEAD to the domain name. The expected response is a 404 or 403 status, indicating the server is refusing access. If the page shows a line that starts with ref: followed by a branch reference, the repository is openly reachable and the source is exposed.

The same check works with a lightweight command‑line tool that follows redirects and prints the HTTP status. Running the test takes only a few seconds and does not require any special permissions.

Preventing the problem at build and deployment time

The most reliable way to avoid accidental exposure is to keep the .git folder out of the directory that the web server serves. Deploy only the compiled or static output of the project, using tools that copy just the needed files. Options include creating an archive of the build directory, or synchronizing files with an exclusion rule that skips any hidden paths.

If the workflow requires a repository checkout in the build environment, add a step that removes the .git folder before the files are moved to production. This approach eliminates the need for additional server rules and reduces the risk of forgetting to update a configuration later on.

Server‑side safeguards you should enable

Even with careful deployment, adding a server rule that blocks dot‑prefixed paths adds a safety net. For an nginx setup, a location block that matches any path starting with a dot and returns a 404 response will stop the .git folder from being served. The rule also excludes the well‑known directory used for certificate challenges, preserving legitimate functionality.

For Apache, a simple redirect match that forces a 404 on any request for a hidden directory achieves the same result. After applying the rule, verify that the test from the earlier section now returns the expected error code while the rest of the site continues to load normally.

Copy-paste reference

location ~ /\.(?!well-known/) {
    deny all;
    return 404;
}