.git Config Exposure.

Security Sensitive File Exposure

Exposed Git config lets attackers discover repo structure and remote URLs

What does this check test?

This check tests whether the `.git/config` file is publicly accessible by requesting `/.git/config`. The Git config file contains repository metadata including remote URLs (which may point to private GitHub/GitLab repositories), branch information, and sometimes credentials. If this file is accessible, it strongly indicates the entire `.git` directory is exposed, which can lead to full source code disclosure via tools like git-dumper.

Why does it matter?

An exposed `.git/config` reveals your private repository URL, which may contain access tokens or organization names that help attackers identify other targets. More critically, if `.git/config` is accessible, the entire `.git` directory (including the object database) is likely accessible too. Attackers can use tools like `git-dumper` to reconstruct the entire repository history, including source code, configuration files, hardcoded secrets, and commit messages that may reference internal systems.

Who is affected?

This issue most commonly affects sites deployed by copying files directly to a web server (e.g., via FTP, rsync, or `cp -r`) where the `.git` directory is included in the deployment. It also affects Docker containers built from a context that includes `.git`, and PHP applications where the web root is the project root. Modern deployment platforms (Vercel, Netlify, Heroku) are generally not affected because they build from source and do not include `.git` in the served output.

Where does this apply?

Test by requesting `/.git/config` from your site. If you receive a response containing `[core]` or `[remote "origin"]`, the file is exposed. Also check `/.git/HEAD` and `/.git/refs/heads/main`. The exposure occurs when the `.git` directory exists within the web server's document root and there is no rule blocking access to it.

How to fix it

Block access to the `.git` directory at the web server level. For Nginx:

nginx

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

Apache

apache

RedirectMatch 404 /\.git

Better yet, exclude `.git` from deployments entirely:

bash

# In your deployment script
rsync -av --exclude='.git' ./build/ server:/var/www/

Docker, add to `.dockerignore`

.git

If you discover an exposure, assume the entire source code and commit history has been compromised. Rotate any credentials found in the repository history, not just the current version.

References

AppVet checks .git Config 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