AppInspected

Fix guides

Your .git folder can be downloaded from your website.

Last reviewed October 16, 2026 against the providers' current documentation.

The short version

Remove the .git folder from what you deploy, block requests for hidden files at your host, and rotate every secret that was ever committed to the repository. Deleting the folder doesn't protect keys that were already downloaded.

Why it matters

The .git folder is your repository's full history. If a web server publishes it, the files can be fetched one by one and reassembled into your complete source code, including old commits. Any API key, password or .env file that was ever committed, even if you deleted it later, comes along with it.

Fix it, in this order

  1. Check it yourself

    Open https://yoursite.com/.git/HEAD in a private window. Every Git repository has a HEAD file, and it usually contains one line like ref: refs/heads/main. If you see that, the folder is exposed. If you see your normal homepage or a 404, it isn't.

  2. Stop deploying it

    This happens when the folder your host publishes is the project root rather than a build folder. Point your host at the build output (dist/, build/, out/) or, for a plain static site, deploy with a command that copies files without .git. Firebase Hosting's default firebase.json already ignores dotfiles with "**/.*"; keep that line.

  3. Block dotfiles at the server

    As a safety net, refuse requests for hidden paths. On nginx:
    location ~ /\.(git|env) {
    deny all;
}
    On Apache (in the site config or .htaccess):
    RedirectMatch 404 /\.git
    Reload the server and recheck /.git/HEAD.

  4. Rotate every secret in the history

    Assume the whole history was copied. Search it for keys with git log -p or a secret scanner, and rotate each one in the provider's dashboard. GitHub's own guidance is that revoking or rotating a leaked secret comes first, and is often enough on its own.

  5. Decide whether to rewrite history

    Only after rotating, you can remove secrets from the history with a tool such as git-filter-repo. GitHub warns that rewriting history has side effects for everyone working on the repository, so skip it unless you need it.

Or ask your AI tool to do it

Paste this into Lovable, Bolt, Cursor, Claude Code or whichever tool built your app. Review what it changes before you deploy.

My website is serving the .git folder (yoursite.com/.git/HEAD loads). Change the deployment so only the build output folder is published and no dotfiles (.git, .env) are ever included. Add a server or host rule that returns 404 or 403 for any path starting with /.git or /.env. Then search the full git history for API keys, tokens, passwords and .env files, and give me a list of every secret I need to rotate, with the provider for each.

How this happens

It's common on simple hosting: you clone the repository onto a server and point the web server at that folder, or you upload the whole project directory. The .git folder is hidden in most file browsers, so nobody notices it went along.

Check that it's really fixed

After you deploy, run the free check. It reads your live site the way an attacker would and tells you if any secret key is still visible.

Check my app free

Questions

My repository is public on GitHub anyway. Does this matter?

Less, because your code is already public. But check whether the deployed copy includes anything that isn't on GitHub, and still rotate any secret that was ever committed.

I deleted the folder. Am I safe?

Not if it was reachable before. Treat every secret in its history as leaked and rotate it.

Sources

Related guides