.git HEAD Exposure.

Security Sensitive File Exposure

Confirms the entire .git directory may be downloadable — full source code leak

What does this check test?

This check tests whether the `.git/HEAD` file is publicly accessible. The HEAD file is a simple text file that typically contains `ref: refs/heads/main` (or another branch name), indicating which branch is currently checked out. While the HEAD file itself contains minimal information, its accessibility is the strongest indicator that the entire `.git` object database is exposed, enabling full source code reconstruction. This check complements the `.git/config` check and confirms the severity of the exposure.

Why does it matter?

The `.git/HEAD` file is the entry point for reconstructing a Git repository. Once an attacker confirms HEAD is accessible, they can systematically download the Git objects by following references from HEAD to commits, trees, and blobs. Tools like `git-dumper` automate this process and can recover the entire repository including all historical commits, branches, and tags. This means every version of every file ever committed — including files that were later deleted — can be recovered.

Who is affected?

Sites deployed with the `.git` directory in the web root are affected. This commonly happens with manual deployments (FTP, SCP, rsync without exclusions), CI/CD pipelines that copy the full project directory, or Docker images built without `.dockerignore`. Static site generators that output into the project directory rather than a separate build folder are particularly prone to this issue.

Where does this apply?

Test by requesting `/.git/HEAD` from your site. A response containing `ref: refs/heads/` confirms the exposure. If HEAD is accessible, also probe `/.git/objects/`, `/.git/refs/`, and `/.git/config` to assess the full scope. Attackers typically use `/.git/HEAD` as the initial probe because it returns a predictable format that is easy to fingerprint.

How to fix it

The fix is the same as for `.git/config` exposure — block access to the entire `.git` directory:

nginx

# Nginx
location ~ /\.git {
    deny all;
    return 404;
}

However, the best approach is to never deploy `.git` to production:

dockerfile

# Dockerfile
COPY --from=builder /app/dist /var/www/html
# Never copy .git into the final image

existing deployments, remove `.git` from the web root

bash

rm -rf /var/www/html/.git

After remediation, assume the repository was already cloned by attackers. Audit the entire commit history for hardcoded secrets and rotate them.

References

AppVet checks .git HEAD Exposure automatically

Run a free security scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit

← All checks