Fix today
Your site's source code folder is downloadable
Your site's .git folder, which holds its source code and full change history, can be downloaded by anyone. Block access to it today, then check that history for passwords and keys and change any you find. Blocking alone does not help if a copy was already taken.
Your site's source code folder is downloadable. https://yourbakery.com/.git/HEAD is publicly readable. It can contain your whole code history, sometimes including passwords.
Ask your developer to block access to the .git folder today, then check the history for any secrets and change them.
What it means
Git is the tool most developers use to track changes to a website's code. It keeps every version of every file in a hidden folder called .git.
That folder is meant to stay on the developer's computer or on the server, out of public view. We found it answering from your live site: yoursite.com/.git/HEAD returns the small file Git uses to record which branch is checked out.
This usually happens when a developer sets up the site by running git clone straight into the public folder, so the .git folder comes along with the code.
Why it matters
Even when a server does not list folder contents, freely available tools can rebuild the whole project from a public .git folder, one file at a time. That gives a stranger your source code and every past version of it.
The history is the real problem. A password or API key that was committed once and deleted later is still in the history. So are old configuration files, internal notes and addresses of admin areas.
With the code in hand, an attacker can look for weaknesses at their own pace instead of guessing. Treat any secret that ever appeared in the history as exposed.
How to check your own site
- In a private browser window, go to
https://yoursite.com/.git/HEADon your own site. - If you see a short line like
ref: refs/heads/main, or a long string of letters and numbers, the folder is exposed. - A "403 Forbidden" or "404 Not Found" page, or your normal site, means it is blocked at that address. Also try
https://yoursite.com/.git/config, which should be blocked too.
How to fix it
Any website
- Step 1, block the whole
.gitfolder, not justHEAD. Use the section below that matches your setup, then confirm the check above now fails. - Step 2, ask your developer to search the full history for secrets: database passwords, API keys, email passwords,
.envfiles and private keys. Anything they find must be changed at the service it belongs to. Removing it from the history does not help, because a copy may already exist. - Step 3, if your hosting keeps access logs, look for successful requests to paths starting with
/.git/. Many in a short time suggests someone downloaded it. - Longer term, deploy the site without the
.gitfolder, so there is nothing to block.
WordPress
- A
.gitfolder in the main WordPress folder usually means a developer manages the site with Git. Themes and plugins installed from Git can have their own.gitfolders insidewp-contenttoo. - Add a server rule that blocks
.gitanywhere on the site (see "Apache or Nginx" below). On managed WordPress hosting, ask support to block it for you. - Then have your developer review the history. Pay attention to
wp-config.php, which holds the database password and security keys. If it was ever committed, change the database password and generate new security keys, which signs everyone out.
Shopify, Squarespace, Wix and other hosted builders
- These platforms do not serve a
.gitfolder on your domain. If we found one, the address we checked is probably served by something else, such as an old server or a separate app. - Ask your developer, or check your domain's DNS settings, to find out what answers at that address. Then block the folder there and review the history as described above.
cPanel hosting
- Open File Manager. Under Settings (top right), turn on "Show Hidden Files (dotfiles)". Look for a
.gitfolder insidepublic_htmlor the folder your site runs from. - Do not delete it before asking your developer, since they may use it to update the site. Instead, edit the
.htaccessfile in the public folder and add the Apache rule below. - If you use cPanel's Git Version Control feature, the repository should live outside
public_html, with a.cpanel.ymldeployment file copying only the site files into it.
Cloudflare
- If your site runs through Cloudflare, go to Security, then WAF, then Custom rules (names vary slightly between plans and dashboard versions).
- Create a rule where the URI Path contains
/.git, with the action Block. - This is a quick first step. The folder is still on your server and can be reached if someone finds the server's own address, so block it there too.
Apache or Nginx
- On Apache, add the rule below to the
.htaccessfile in the site's public folder, or to the site configuration. It returns "404 Not Found" for any address containing/.git, at any depth. - On Nginx, add the location block inside the
serverblock for your site, test withnginx -t, and reload.
# Apache (.htaccess or site config)
RedirectMatch 404 /\.git
# Nginx (inside the server block)
location ~ /\.git {
deny all;
}
What to send your developer
/.git/ is served publicly, so the repository can be reconstructed from its objects even without directory listing. Deny every path under .git at the web server, including nested repositories in themes or plugins. Deploy build output or a git archive export instead of a working copy in the web root. Then audit the full history, all branches included, for credentials, and rotate everything found. Rewriting history is optional cleanup; it does not help against a copy that was already taken. Check access logs for 200 responses under /.git/.
git log --all -p | grep -inE "password|secret|api[_-]?key|token"
Common questions
The folder only has code in it. Is that really a problem?
Yes, for two reasons. The history often holds passwords or keys someone committed by mistake, even if they were deleted later. And the code itself shows an attacker exactly how your site works and where it might be weak.
Can I just delete the .git folder from the server?
That removes the exposure, but check with your developer first. If they update the site by pulling changes with Git on the server, deleting the folder breaks that. Blocking it with a server rule is safe to do right away.
Do I need to change passwords if nothing sensitive was ever in the code?
Only your developer can say that with confidence, after searching the full history, including old branches. If they find nothing, blocking the folder is enough. If there is any doubt, change the database password and main API keys.