Web 应用中“敏感信息泄露“的常见位置？

------注释、硬编码 API Key、报错信息、Git 泄露，攻击者是如何利用它们的？

你有没有想过，很多网站被攻破，并不是因为 SQL 注入，也不是因为命令执行，而是开发自己把"钥匙"放到了门口。

一段 HTML 注释、一份 Git 仓库、一个写在 JS 里的 API Key，都可能让攻击者几分钟内摸清整个系统。

今天聊聊企业中最容易被忽略的一类安全问题------敏感信息泄露。

什么是敏感信息泄露？

简单来说，就是本不应该公开的信息，被未授权用户获取了。

例如：数据库账号密码、API Key、AccessKey、Token、Cookie、Git 源码、配置文件、报错信息、后台地址等。这些信息单独看可能不起眼，但组合起来，往往足以帮助攻击者进入系统。

攻击流程通常如下：信息收集 → 发现敏感信息 → 获取账号/密钥 → 登录后台或调用接口 → 数据泄露。

常见的敏感信息泄露位置

1. HTML 注释：别以为用户看不到

开发调试时，常会留下这样的内容：

复制代码




虽然页面不会显示，但任何人都可以通过查看网页源码看到这些内容。建议：上线前删除所有调试注释，不要在注释中保存账号、密码或内部地址。

2. JavaScript 文件：千万不要把 API Key 写在前端

前端 JS 文件经常会包含接口地址、调试配置，甚至有人会把 API Key 写进去：

复制代码

const API_KEY = "xxxxxxxx";

由于 JS 会被浏览器下载，任何访问网站的人都可以查看。记住一句话：真正需要保密的数据，永远不要放在前端。

前端代码可以公开，但真正的密钥永远不能公开。

3. Git 仓库泄露：一次泄露，整个源码都没了

如果生产环境开放了 .git目录，攻击者可能恢复整个源码仓库。源码中往往包含：数据库配置、Redis 密码、JWT Secret、管理接口、历史提交记录等。这也是企业中最常见的信息泄露问题之一。

Git 泄露最大的风险不是源码，而是源码里的各种"钥匙"。

4. 报错信息：别把系统"底牌"告诉攻击者

生产环境如果直接返回详细异常，例如 SQLSyntaxErrorException或者 D:\project\web\，攻击者就能知道数据库类型、服务器路径、框架版本等重要信息，从而降低攻击难度。建议：生产环境统一返回友好的错误页面，详细日志仅保留在服务器。

生产环境应该记录详细日志，但展示给用户的错误信息越少越好。

5. 配置文件和备份文件：这些"垃圾"最容易出事

很多企业会遗留 .env、application.yml、config.php、backup.zip、website.bak等文件。这些文件可能包含数据库密码、云平台密钥等敏感信息。上线前一定要清理，避免放在 Web 可访问目录。

很多数据泄露，不是因为漏洞，而是因为忘了删除一个备份文件。

6. Swagger、Actuator、Source Map：方便了开发，也方便了攻击者

这些工具本来是为了方便开发和运维，但如果直接暴露在生产环境，就可能泄露接口文档、系统配置、环境变量、前端源码等。建议生产环境关闭，或至少增加访问控制。

开发工具可以保留，但生产环境不应该对所有人开放。

一个简单的攻击案例

攻击者访问网站后，没有急着扫描漏洞，而是先查看 robots.txt、swagger-ui、main.js、/.git等常见位置。随后恢复源码，获取数据库配置和测试账号，再结合公开的接口文档，最终登录后台并导出数据。整个过程中，没有利用任何高危漏洞，仅依靠敏感信息泄露就完成了攻击。

给开发/测试的 Checklist

检查项	开发注意事项	测试方法
HTML 注释	删除调试注释	查看页面源码
JavaScript	不保存 API Key、密码	搜索 key、secret、token
Git 仓库	不部署 .git	检查 /.git/HEAD
报错信息	关闭调试模式	构造异常请求
配置文件	不放 Web 目录	枚举 .env、.yml
备份文件	删除 .zip、.bak	扫描常见备份文件
Swagger/Actuator	生产环境关闭或鉴权	检查是否开放

总结

很多数据泄露事件，并不是因为攻击者掌握了多么高深的技术，而是因为系统提前把"钥匙"放在了容易找到的地方。一次 HTML 注释、一份备份文件、一个公开的 Git 仓库，都可能成为攻击链的起点。

因此，无论是开发还是测试，都应把敏感信息泄露检查纳入每次上线和安全测试的固定流程。及时清理调试信息、妥善保管密钥、关闭不必要的调试功能，往往比修复一个漏洞更能降低安全风险。