criticalSeverity: criticalRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Deploy config / web serverWhere it livesImplementationThis fix is applied in: Deploy config / web server. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+40 posture+40 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed .git: take your source code back off the public internet

Blocking /.git and rotating any committed secrets stops anyone from downloading and rebuilding your entire codebase

The threat

The scanner asked for /.git/HEAD and got back a valid git reference. That one response means the whole .git folder is sitting under your web root, and .git is not just your current files: it is every version, every branch, every file ever committed. Off-the-shelf tools like git-dumper walk that folder over plain http and rebuild your entire working tree on someone else’s laptop, no login required.

The part that surprises people is the history. Anything ever committed comes back too: an old config with a database password, an API key someone pasted in and “removed” the next week, private comments. Deleting a secret in a later commit does not remove it from the repository, so this is two problems at once: your source is now public, and every credential that ever lived in it is now public.

The exact fix

Step 1, contain: rotate every secret that has ever been committed. Because git keeps full history, “we deleted that line months ago” does not help you here. Scan the history and rotate anything sensitive it turns up:

  • Run a secret scanner over the repo (gitleaks detect or trufflehog git file://.), or git log -p and read.
  • Rotate what it finds: database passwords, API keys and tokens, signing keys, webhook secrets. Treat each as public.

Step 2, stop serving the repository. Two parts, and the first is the real cure:

  • Deploy build output, not the repo. The web root should contain compiled or built files, never the .git folder. If your server deploys by running git pull into the served directory, that is the root cause: switch to publishing built artifacts into a clean directory. On a static host like Netlify only the build output ships, so there is no repository to serve.
  • Block the path at the server as a backstop.

nginx:

location ~ /\.(git|svn|hg) {
    deny all;
    return 404;
}

Apache (vhost or .htaccess):

# Apache 2.4
RedirectMatch 404 "/\.git"

The block is the seatbelt, not the cure. If a working git checkout is your web root, blocking /.git hides the symptom while the repo is still one misconfiguration away from exposure. Fix the deploy so built artifacts, and only built artifacts, land in the served directory.

Verify it

curl -sI https://yourdomain.com/.git/HEAD

You want HTTP/2 404 (or 403). A 200 means the folder is still being served, and you can confirm it by fetching the body: if ref: refs/heads/... comes back, anyone can clone you.

Proof

The ApeCyber scanner flags this passively, from the outside, with a single GET of /.git/HEAD, touching nothing else. apecyber.com deploys built artifacts to Netlify, so the repository never reaches the web root and there is nothing at /.git to fetch. At −40 this is the single heaviest line on a posture score, and it clears the moment the repo stops being served and any committed secrets are rotated.