🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4 · Curated by Tom Hundley
If your website publicly exposes /.git/config, attackers may be able to read repository settings and, in some cases, embedded credentials or access tokens. The immediate risk is not that every exposed config file contains a password. The real problem is that some do, and even when they do not, an exposed .git directory can still help an attacker reconstruct source code, map your deployment setup, and look for other secrets.
The safest assumption is simple: if /.git/config or /.git/HEAD is reachable from a browser, you have a security issue that needs to be fixed now. Start by checking your live site, blocking public access to .git, and rotating any credentials you find embedded in remote URLs. If you deploy to shared hosting or copy full project folders to a web root, your risk is much higher than on platforms that publish only build artifacts.
You may already know that exposing a .git folder is bad. You may even have read about how to check if your site is vulnerable or how to fix it before you deploy. What matters here is the specific file many teams overlook: .git/config.
TL;DR: .git/config stores repository-specific Git settings. It does not always contain secrets, but when credentials are embedded in remote URLs, an exposed file can hand attackers direct access.
The .git/config file is Git's local configuration file for a repository. It commonly stores:
A typical entry looks like this:
[remote "origin"]
url = https://github.com/your-username/your-project.gitThat version is not ideal to expose, but it is far less dangerous than this:
[remote "origin"]
url = https://your-username:YOUR_PASSWORD_HERE@github.com/your-username/your-project.gitIf credentials are embedded directly in the URL, anyone who can read the file may be able to reuse them. That can lead to unauthorized repository access, malicious commits, or access to other systems tied to the same account.
This pattern is less common than it used to be because GitHub removed password authentication for Git over HTTPS in 2021, pushing users toward personal access tokens, SSH keys, and credential helpers. But embedded credentials still appear in the wild, especially with older setups, self-hosted Git services, automation scripts, and misconfigured tools.
If you use AI coding tools, the risk is not that they uniquely create this problem. The risk is that automation can hide what is being configured on your behalf. A tool may set a remote, cache a token, or generate deployment files without making the security implications obvious. That is why it is worth checking both your Git config and your deployment output, especially if you also rely on tools that manage secrets for you. Related issues show up in how AI coding assistants can leak your API keys.
TL;DR: Source code exposure is serious, but exposed .git/config files can be worse when they reveal credentials, internal repository locations, or clues that help attackers pivot.
Here is the practical hierarchy of risk:
| What's Exposed | What an Attacker Gets | Severity |
|---|---|---|
.git/objects or enough of .git to reconstruct history |
Source code, commit history, deleted files, and developer notes | Serious |
.git/config without credentials |
Repository URLs, branch names, workflow clues, and infrastructure hints | Moderate |
.git/config with embedded credentials or tokens |
Potential repository access and the ability to read or modify code | Critical |
.git/config plus exposed secret files such as public .env files |
A path to databases, cloud services, CI systems, and user data | Catastrophic |
The biggest difference is read access versus write access. If attackers can reconstruct your code from an exposed .git directory, they learn how your application works and can search for vulnerabilities or secrets. If they also obtain valid credentials from .git/config, they may be able to push malicious code, tamper with CI pipelines, or access private repositories.
That turns a server misconfiguration into a software supply chain problem. The exact blast radius depends on the permissions attached to the leaked credential. A narrowly scoped token is bad. A broadly scoped token tied to CI, package publishing, or production deployment is much worse. This is the same general class of risk discussed in GitHub Actions security and supply chain attacks.
TL;DR: Test /.git/config and /.git/HEAD in a browser or with curl. If either is accessible, block the directory immediately and rotate any exposed credentials.
Open a browser and try:
https://yoursite.com/.git/confighttps://yoursite.com/.git/HEADYou can also use curl:
curl -i https://yoursite.com/.git/config
curl -i https://yoursite.com/.git/HEADIf you see content such as [core], [remote "origin"], or ref: refs/heads/main, your .git directory is exposed.
A proper 403 or 404 response is what you want. A redirect to your homepage is less clear; test carefully, because some servers rewrite missing paths in ways that can hide the issue.
Open your local .git/config file and look for remote URLs that contain credentials, such as:
https://user:token@host/repo.githttps://token@host/repo.gitIf you find anything like that, treat it as compromised if the live file was publicly accessible.
.git immediately..env, .npmrc, deployment configs, and backup archives.Shared hosting with Apache:
RedirectMatch 404 /\.gitA stricter option is to deny access to all dotfiles except well-known exceptions your site needs.
Nginx:
location ~ /\.git {
deny all;
return 404;
}Modern deployment platforms:
Platforms such as Vercel and Netlify generally publish build output rather than your full project directory, which greatly reduces the chance of exposing .git. That said, you should still verify your deployment model rather than assume every environment behaves the same way.
TL;DR: The highest risk is on servers where your full project directory becomes the public web root, especially shared hosting, manual uploads, and ad hoc VPS deployments.
| Hosting Platform | .git Exposure Risk |
Why |
|---|---|---|
| Vercel | Very low | Typically serves build output, not the repository directory |
| Netlify | Very low | Same pattern: published artifacts rather than raw source |
| Render / Railway | Low | Usually containerized or build-based, though configuration still matters |
| Replit Deployments | Low | Managed deployment reduces risk, but exported projects can still be mishandled |
| Shared hosting with cPanel or FTP | High | Full project folders are often uploaded directly |
| Manual VPS setup | High | Cloning or copying a repo into the web root can expose .git |
| Generic cloud VM | Medium to high | Safe when configured well, risky when convenience wins |
The common failure mode is simple: someone uploads the entire project folder, including hidden directories, into a publicly served location. That is especially common with FTP workflows, file-manager uploads, and quick server setups.
If your deployment process is manual, add a preflight check that confirms hidden files and directories are excluded. Better yet, deploy build artifacts or container images instead of the working repository.
TL;DR: Ask your AI tool to check deployment output, not just source code, and to look specifically for hidden files, embedded credentials, and public dotfile exposure.
Paste this into your AI coding tool before you deploy:
I'm about to deploy this project to [your hosting platform].
Please check:
1. Will any .git directory or file be publicly accessible after deployment?
2. Does .git/config contain embedded credentials, tokens, or authenticated remote URLs?
3. Does the server or platform configuration block access to hidden files and directories?
4. Are there any other sensitive files such as .env, .npmrc, backup archives, or config files that could be served publicly?
5. What exact changes should I make for this platform before deployment?
If you find a risk, explain the issue briefly and give me the safest platform-specific fix..git directory is always a security problem..git/config file is especially dangerous when it contains embedded credentials or tokens./.git/config or /.git/HEAD is reachable, block access and rotate credentials immediately.Open the file locally and inspect the url = lines under your remotes. If the URL includes a username and secret before the @ symbol, such as https://user:token@host/repo.git, credentials are embedded in plain text. A normal remote URL like https://github.com/org/repo.git does not expose a secret by itself.
Usually no. These platforms generally deploy built output rather than the raw repository directory. That makes accidental .git exposure much less likely than on shared hosting or manual server setups. Still, verify your actual deployment path and any static file publishing rules.
It depends on the credential type and scope. They may be able to clone private repositories, push malicious commits, access CI systems, or reuse the credential against related services. If the token has broad permissions, the impact can extend well beyond a single repository.
You are generally safer on managed deployment platforms than on manual hosting, but not automatically safe in every workflow. If you export a project and upload it elsewhere, or if a custom deployment copies the full repository into a public directory, you can still create the same exposure.
Check whenever you change hosting providers, deployment methods, reverse proxy rules, or build pipelines. A quarterly sweep of all live sites is a reasonable baseline, and any internet-facing project should be tested before and after launch.
If your site exposes /.git/config, do not wait for a fuller investigation before acting. Block access, inspect the file locally, rotate anything sensitive, and review your deployment process so the same mistake does not happen again.
If you want a second set of eyes on your deployment workflow, ESS can help you audit what is actually being published, lock down hidden files, and build a safer release process before the next push goes live.
Share this with someone deploying their first project. A ten-second check can prevent a very bad week.
Discover more content: