Exposed .git scanner for safer web app launch checks

An exposed .git scanner checks whether your deployed app is leaking Git metadata, such as HEAD, config, index, refs, or logs. The direct answer: test the public URL for readable Git paths, confirm whether files reveal source history, then block access and rotate anything sensitive found in reachable commits. Do this before launch, not after search engines or attackers index it.

What an exposed .git scanner should catch?

A good scan does more than request one URL and report a 200 response. It checks whether the server exposes enough Git internals to reconstruct code, infer branch names, or discover credentials in old commits. The risk is not the folder name itself, it is public Git metadata that lets someone rebuild what should be private.

The first pass should look for:

/.git/HEAD returning a branch reference instead of a 403 or 404
/.git/config revealing remote URLs, usernames, or repository structure
/.git/index being downloadable with a non-trivial file size
/.git/logs/HEAD exposing commit history and local paths
/.git/objects/ paths responding in a way that supports object recovery
Directory listing on hidden paths, especially on static hosts or misconfigured Nginx

The most serious finding is a recoverable public Git directory. In practice, a scanner should classify that above a cosmetic hidden-file issue because it can expose application code, deleted secrets, database names, internal endpoints, and deployment scripts.

The scanner should also catch adjacent leak patterns. A .git directory exposure often appears beside source map clues, forgotten backup archives, public .env files, or old build outputs. If your release process has one file placement mistake, it may have several. Pair this check with a public .env exposure review and a website secret scanner pass.

Run a safe exposure check

Only scan authorized domains only. For your own staging and production apps, a safe check should use read-only HTTP requests, short timeouts, and no attempt to exploit unrelated services. Avoid recursive downloads until you have confirmed ownership and business need.

A simple manual probe can show whether the server is clearly blocking common paths:

bash

TARGET=https://example.com

for path in /.git/HEAD /.git/config /.git/index /.git/logs/HEAD; do
  status=$(curl -sk -o /tmp/gitcheck -w %{http_code} ${TARGET}${path})
  bytes=$(wc -c < /tmp/gitcheck)
  echo ${status} ${bytes} ${path}
done

rm -f /tmp/gitcheck

This script is not a full audit, but it demonstrates the signals that matter. A 404 for every path is usually good. A 403 can be acceptable if the rule is intentional and consistent. A 200 with meaningful file contents should be treated as confirmed exposure.

Use read-only probes and compare both status and body signals. Some frameworks return the app shell with 200 for every unknown route. That can create false positives unless the scanner checks content patterns such as ref: refs/heads/main, [core], binary index signatures, or Git log formatting.

For AI-built apps, this check is especially useful because the deployment path is often assembled quickly: generated code, default static hosting, copied server snippets, and manual file uploads. The risk rises when a project is built locally, zipped, and uploaded with hidden files intact.

If you need broader coverage, run the Git check inside a wider attack surface checks workflow. AISHIPSAFE also supports a deeper prelaunch review through deep scan when you need more context than a single endpoint probe.

Fix confirmed git exposure

If you confirm a Git metadata leak, do not only add a deny rule and move on. Assume that anything in reachable commits may have been public. Git history can preserve deleted secrets, old configuration values, API routes, test credentials, and comments that reveal internal logic.

Start with stop after confirmation. You do not need to download the full repository to prove impact if HEAD, config, and index are readable. Full reconstruction can increase handling risk and may copy sensitive data to developer machines or CI logs.

Then apply fixes in this order:

Remove the directory from the deployed artifact. Production builds should not contain .git at all.
Block hidden paths at the edge, reverse proxy, and origin where possible.
Rotate exposed credentials found in current files or prior commits.
Review logs for access to /.git/ paths, especially before the fix time.
Purge cached copies from CDN, object storage, and preview deployments.
Rebuild and redeploy from a clean artifact, not the same uploaded directory.
Add a release check so the issue cannot return on the next deploy.

For Nginx, a defensive rule can block hidden dot paths while allowing required well-known files:

nginx

location ~ /\.(?!well-known/) {
  deny all;
  return 404;
}

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

Apply the same idea wherever your app is hosted. Static hosts, container images, object buckets, and reverse proxies each need their own control. A rule on the CDN is helpful, but the origin should still be safe if the CDN is bypassed.

A Git metadata leak should trigger a secret review. Check API keys, database URLs, OAuth secrets, webhook signing secrets, JWT keys, private package tokens, and cloud credentials. If a credential was ever committed, rotation is safer than trying to prove nobody accessed it.

Prelaunch checklist

Use this short checklist before publishing a new app, especially after rapid AI-assisted development or manual deployment changes.

Confirm /.git/HEAD, /.git/config, and /.git/index are not readable.
Check staging, preview, custom domains, and the bare hosting URL.
Verify the response body, not just HTTP status codes.
Search build artifacts for .git, .env, .bak, .zip, and source maps.
Confirm CI produces a clean artifact from build output only.
Add deny rules for hidden paths at the origin and edge.
Run secret scanning after any confirmed repository metadata exposure.
Add this check to your launch gate and repeat it after hosting changes.

The most common failed audit pattern is simple: production serves the repository root instead of a built output directory. Another common pattern is copying a local project folder to a server with scp or drag-and-drop upload, which includes hidden files by default.

Before and after matters. Before the fix, /.git/HEAD returns ref: refs/heads/main. After the fix, it should return a consistent 404 or 403 from both the CDN and the origin. If only the CDN blocks it, document the exception and fix the backend next.

Keep monitor regressions in mind. A deployment script, hosting migration, or new preview environment can reintroduce the same issue months later. If you already run prelaunch vulnerability checks, include this as a small but high-signal test in the same workflow.

A public .git folder is usually a deployment hygiene failure, not an advanced attack. Treat it seriously because the blast radius can include old secrets and source history. Fix the artifact, rotate what was exposed, and keep the check automated before every important release.

Faq

Is a 403 response safe for git paths?

Usually, yes, if every Git-related path returns the same blocked response and the body does not reveal file contents. Still test multiple paths, including HEAD, config, index, and logs/HEAD. A mixed result, such as 403 on the folder but 200 on files, is still a real issue.

Can attackers rebuild code from git metadata?

Sometimes. If Git objects, refs, index files, and logs are reachable, attackers may reconstruct large parts of the repository. Even partial recovery can expose routes, environment variable names, deleted credentials, and business logic. Treat readable metadata as sensitive, even before proving complete source recovery.

Should i rotate secrets after fixing access?

Yes, rotate any secret that appears in current files or historical commits that may have been reachable. Blocking the path stops future access, but it does not undo previous downloads. Prioritize production database credentials, payment keys, cloud tokens, OAuth secrets, and webhook signing keys first.

If you want a fast second pass before launch, run an AISHIPSAFE security scan. It checks practical exposure signals without turning your prelaunch review into a heavy audit.