Exposed .git directory

When a website is deployed by copying a Git repository "as is", the hidden .git/ directory ends up served under the web root. That directory holds the entire project history: the compressed object tree, commits, branches and, above all, files that normal browsing never reveals (config, credentials, internal paths, unpublished code). An accessible .git/ over HTTP is effectively leaking the full source code.

How to confirm it (attacker). Just request a known file from the directory. A 200 means .git is exposed:

curl -s http://shop.example.com/.git/HEAD      # ref: refs/heads/master  -> exists
curl -s http://shop.example.com/.git/config    # remotes, paths...

Sometimes the server even allows listing the index (Index of /.git), confirming at a glance that HEAD, config, objects/, refs/, logs/, etc. are all there.

How to exploit it. No need to clone object by object: tools like git-dumper reconstruct the local repository by downloading the index and every reachable blob:

git-dumper http://shop.example.com/.git/ ./loot
cd loot && git log --all --oneline        # full history

Once rebuilt, review the history (git log, git show) and the files the server did not serve: the web server applies rules that hide or deny certain directories, but those files do live inside the .git blobs, so git-dumper recovers them anyway. That's the gap between what the browser can see and what the repository contains. The git log also leaks the author (name and email), useful as a username for later access, a credential reuse, or a spray.

How to detect it. The access-log signature is a flood of requests to /.git/... paths (/.git/HEAD, /.git/index, /.git/objects/xx/...), which no browser requests, from a single IP in a short time, often with the git-dumper/wget User-Agent. A 200 on /.git/HEAD followed by hundreds of objects/ downloads is the unmistakable pattern; a WAF denying access to /.git/ cuts it and logs it at the same time.

Defence. Don't deploy with .git inside the web root; if you do, deny access to .git in the server config (Require all denied / location ~ /\.git). Better still, publish only the build, not the repository. Related to the command execution that usually follows once the leaked code reveals a vulnerable version or a credential.