To fix an exposed .git directory, block web access to /.git immediately (server deny rules), then audit git history for committed secrets and rotate any that were exposed. Never deploy the .git folder to production web roots.
When the /.git directory is web-accessible, attackers can reconstruct your source code and browse commit history — often finding old API keys and passwords that were committed and later removed. Blocking access and rotating any exposed secrets fixes the immediate risk.
Check your website
See how your site handles how to fix an exposed .git directory — free, no account needed.
Business impact
Source code exposure gives attackers a map of your application — endpoints, auth logic, and hardcoded secrets in old commits. It accelerates targeted attacks and is a critical finding in any security audit. Deployment hygiene (never publishing .git) prevents it entirely.
Why this happens
The scanner checks /.git/config, /.git/HEAD and /.git/index for HTTP 200 with git-specific content. This happens when developers deploy via git pull directly in the web root, use FTP and upload the whole project including .git, or misconfigure CI/CD. Tools exist to fully dump a repository from a partially exposed .git folder.
How to confirm the issue
Manually: visit https://yoursite.com/.git/config. Readable git config content means the repository is exposed.
With Plexa Trust: look for "Git Repository Exposed" or "Git HEAD Exposed". Re-scan after blocking access.
Step-by-step fix
Block web access to
/.gitvia server config (deny all dot-directories).Remove the
.gitfolder from the production web root if it should not be there.Audit git history for secrets:
git log -por tools like gitleaks/trufflehog.Rotate any API keys, passwords or tokens ever committed — even if later removed from HEAD.
Fix deployment: build artifacts only in web root, never the full git repo.
Re-scan to confirm /.git paths return 403/404.
Platform-specific fixes
Apache
RedirectMatch 404 /\.git
Or: <DirectoryMatch "\.git"> Require all denied </DirectoryMatch>
Verify /.git/HEAD returns 404.
Nginx
location ~ /\.git { deny all; return 404; }
Reload nginx and test.
Correct deployment
CI/CD should deploy built assets only (e.g. dist/, public/) — not .git.
For PHP: deploy application files without .git, or use git pull outside web root.
Add .git to deployment exclude lists in rsync/FTP clients.
Secret scanning
Run gitleaks or trufflehog on your repository.
Rotate every secret found in history.
Consider git filter-repo to purge secrets from history if repo is private.
How to verify the fix
Never deploy .git to production web-accessible directories.
Use .gitignore for .env and secrets; scan commits in CI.
Block dot-directories at the server as defence in depth.
Re-scan with Plexa Trust and confirm git findings clear.
Common mistakes
git pull in public_html on shared hosting, leaving .git web-accessible.
Removing .git from HEAD but not rotating secrets still in history.
Assuming a private GitHub repo means production .git exposure is fine — it is not.
Only blocking config but leaving other .git files readable.
Frequently asked questions
Can attackers download my whole repo from /.git?
Often yes — tools exploit partially exposed .git directories to reconstruct the full repository.
I removed the secret from git — am I safe?
No. Old commits may still be accessible via exposed .git or GitHub history. Rotate the secret.
Should .git ever be on the server?
It can exist outside the web root for deployment, but never in a publicly served directory.
What about .svn?
Same risk — block .svn directories. The scanner also checks /.svn/entries.
How do I scan git history for secrets?
Use gitleaks, trufflehog, or GitHub secret scanning. Rotate anything found.
Does .gitignore protect committed secrets?
No. .gitignore only prevents future commits — already committed secrets remain in history.
Is this related to exposed .env?
Often both appear together on poorly deployed apps. Fix both and rotate all secrets.
How do I confirm the fix?
/.git/config and /.git/HEAD should return 403/404. Re-scan with Plexa Trust.
Think you've fixed it?
Run a free scan to verify the issue is resolved. Upgrade to Pro on Plexa Trust for the full audit, monitoring alerts, and score history.
Verify with a free scan