一条 curl 命令, 就有可能把你的源码和密码全扒走

01

.git 目录泄露，到底有多严重

.git目录是 Git 仓库的核心，里面存储了你的一切：

.git/├── HEAD       # 当前分支指针├── config     # 仓库配置（可能有远程仓库地址、token）├── index      # 暂存区索引├── objects/   # 所有对象（完整代码、文件内容）├── refs/      # 分支和标签引用├── logs/      # 引用日志（能看到所有操作记录）├── hooks/     # 钩子脚本└── COMMIT_EDITMSG    # 最近一次提交信息

泄露后，攻击者能做的事远不止"看看代码"：

02

快速检测：你的网站中招了吗

最简单的方法，30 秒搞定：

SHELL · 手动检测# 替换成你的域名，以下任意一条返回 200，说明存在泄露curl -I http://your-site.com/.git/HEADcurl -I http://your-site.com/.git/configcurl -I http://your-site.com/.git/COMMIT_EDITMSG

03

Nginx 配置防护（最推荐）

最直接的方法，在 Nginx 配置中禁止所有.git相关请求。推荐优先用这个方案。

04

Apache配置防护

如果你用的是 Apache，两种方式都能实现防护：.htaccess适合共享主机，主配置文件方案更彻底。

05

服务器层面防护（多重保险）

Web 服务器配置只是第一道防线。从部署流程入手，才能根治这个问题。

方案 1直接删除 .git 目录

如果生产服务器上完全不需要用 git 拉取更新，最简单——直接删掉。rm -rf /var/www/html/.git。注意：如果还需要 git pull 更新，改用部署脚本方案。

方案 2部署脚本（推荐）

克隆到临时目录，用 rsync 排除 .git 后同步到网站目录。根治问题，不留隐患。

方案 3CI/CD 自动化部署

配置 GitHub Actions，推送代码自动触发部署，天然排除 .git 目录，彻底告别手工操作失误。

方案 4Docker 部署（最安全）

容器镜像构建时主动删除 .git 目录，运行时物理隔离，从根本上杜绝泄露风险。

06

其他敏感文件一并防护

既然都配置了，顺手把下面这些也一起防掉。这是一份可以直接贴到 Nginx 的完整配置：

07

检测与监控（事后补救）

防护配置上线后，还需要定期检查和实时监控。发现有人在扫你，早知道比晚知道好。

设置定时任务，每天凌晨自动执行巡检：

08

老宋说

// 老宋的话

.git 目录泄露不是什么高深的技术漏洞，本质是人的问题——图省事、不重视安全规范、部署流程不严谨。我见过太多案例：开发人员直接git clone到生产服务器，运维人员不知道要检查，安全负责人没把这件事放进检查清单。结果呢？攻击者用现成工具一扫，源码、密码、架构全到手。技术本质：Web 服务器没有对敏感目录做访问控制，导致任意用户可以通过 HTTP 访问本应禁止的路径。管理本质：缺乏标准化的部署流程和安全检查清单，依赖个人习惯而非制度。现在就去检查你们所有对外服务的网站根目录，用curl -I http://your-site.com/.git/HEAD测一下，返回 200 的立即按本文第三步处理。