How to Fix an Exposed .git Directory

Your .git directory is publicly accessible, allowing attackers to download your entire source code and commit history. Fix it now.

Critical severity Infrastructure Security Updated 2026-03-01

The Problem

An exposed .git directory allows attackers to reconstruct your entire source code repository, including every file, commit history, branch names, and potentially credentials that were committed and later removed. Tools like git-dumper can automatically download the .git directory and rebuild the full repository. This gives attackers your application code, configuration patterns, and any secrets that were ever committed.

How to Fix

1
Block .git access in Nginx
Add this location block to your Nginx server configuration:

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

This blocks access to .git, .gitignore, .gitmodules, and all subdirectories. Reload Nginx:
```
sudo nginx -t && sudo systemctl reload nginx
```

Block .git access in Apache

Add to your .htaccess or Apache configuration:

RedirectMatch 404 /\.git

Or using a more comprehensive rule:

<DirectoryMatch "^\.git">
    Order allow,deny
    Deny from all
</DirectoryMatch>

3
Ensure document root is correct
Your web server should serve from the /public directory, not the project root. If the document root is correct, the .git directory is one level up and not accessible.
```
# Correct - serves from public/
root /var/www/yourapp/public;
```
```
# Wrong - serves from project root, exposes .git
root /var/www/yourapp;
```
Verify with: curl -I https://yourdomain.com/.git/HEAD

Use deployment without .git on the server

The safest approach is to not have .git on the production server at all. Deploy with rsync excluding .git:

rsync -avz --exclude='.git' ./ user@server:/var/www/yourapp/

Or use git archive to create a clean export:

git archive --format=tar HEAD | ssh user@server "tar -xf - -C /var/www/yourapp/"

CI/CD tools like Envoyer and GitHub Actions can deploy artifacts without the .git directory.

How to Verify

Test that .git is not accessible:

curl -I https://yourdomain.com/.git/HEAD
curl -I https://yourdomain.com/.git/config

Both should return 403 or 404. If you see a 200 response with content like "ref: refs/heads/main", the .git directory is still exposed.

Prevention

Configure your web server to block all dotfile access by default. Deploy without .git on the server. Add .git access checks to your deployment pipeline. Use StackShield to continuously monitor for exposed .git directories.

Frequently Asked Questions

What can an attacker do with my .git directory?

They can download and reconstruct your entire codebase including all historical commits. This reveals source code, configuration files, credentials that were committed and later removed, internal API endpoints, business logic, and vulnerability patterns in your code. Tools like git-dumper automate this process.

I removed secrets from my code. Are they still in .git?

Yes. Git stores all history, so secrets in previous commits remain accessible even after deletion. If your .git was exposed, assume any secret ever committed is compromised. You need to rotate all credentials and optionally rewrite git history with git filter-branch or BFG Repo Cleaner.

Related Guides

Critical

Detect This Automatically with StackShield

StackShield continuously monitors your Laravel application from the outside and alerts you when security issues are found. No installation required.

Start Free Trial