Home / Core Health / Block public access to .git directories and version control files
Exposed Files · Scan Check Guide

Block public access to .git directories and version control files

15 min Impact: high Effort: low ✓ Scan-verified — no manual checkbox

A .git folder contains your site's entire version history — including old code, past credentials that were later removed, and internal comments. If it's accessible in your public web root, tools exist that can reconstruct your entire source code and history from it automatically.

An exposed .git directory lets anyone download your entire source code, including hardcoded credentials, API keys, and internal system details. A critical and surprisingly common exposure.

The full picture

Publicly accessible .git directories expose your site's complete version control history, potentially including genuine sensitive information that was ever committed to the repository, even information later removed from the current codebase — version control systems typically retain full historical records, meaning past mistakes remain accessible even after being "fixed" in the current version.

This exposure provides an attacker with significantly more than just your current source code — the complete commit history often reveals development patterns, potentially exposed credentials from earlier, less careful commits, comments discussing known vulnerabilities or planned fixes, and other genuinely sensitive information never intended for public access.

The common cause of this exposure mirrors the .env file issue discussed elsewhere — version control directories intended purely for development and deployment processes end up within the publicly accessible web root due to deployment configuration oversights, making them directly downloadable by anyone aware of or probing for this common misconfiguration.

Remediation requires both closing the immediate exposure and, genuinely importantly, reviewing what sensitive information might have been exposed throughout your repository's full history if this vulnerability existed for any meaningful period — any credentials or sensitive data ever committed to the exposed repository should be considered compromised and rotated, regardless of whether they remain in the current codebase.

How to fix it

  1. 1
    Check exposure
    Visit https://yoursite.com/.git/config — if it returns real content, your repository is exposed.
  2. 2
    Block access at the server level
    Add a rule denying access to any dotfile/folder (.git, .svn, etc) in your server config — a few lines covers this permanently.
  3. 3
    Confirm your deployment process doesn't publish .git at all
    Ideally .git never ships to your production server in the first place — check your deploy script or CI pipeline excludes it.
  4. 4
    Rotate any credentials found in your git history
    If exposed, assume anyone could have downloaded your full commit history, including any secrets ever committed and later "removed."

Common mistakes

How you'll know it's done

https://yoursite.com/.git/config returns a 403 or 404.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →