上周帮一个做电商的网站朋友查服务器，顺手扫了一遍他网站的敏感前端代码。好家伙，信息注释里赫然躺着一行测试用的自查数据库账号密码，还是报告root权限。这要是网站被爬虫或者有心人扒到，整个订单库就等于敞开大门。敏感他听完脸都白了，信息说这代码是自查两年前外包写的，一直没动过。报告这事让我觉得，网站网站敏感信息自查真不是敏感走形式，很多雷就埋在眼皮底下。信息

先搞清楚要查什么。自查最典型的报告是硬编码凭证——数据库连接串、API密钥、短信平台token、支付接口的商户私钥。这些东西一旦写死在JS文件或HTML注释里，等于把钥匙插在门上。我见过一个后台管理系统，登录接口的加密盐值直接写在源码里，攻击者拿到后可以批量伪造合法请求。还有更隐蔽的，比如调试接口没关，访问 /debug/env 就能吐出所有环境变量。

源码泄露是另一个重灾区。有些团队用webpack打包，但没关source map，浏览器一开开发者工具就能看到完整未压缩的源码，连注释里的内部IP、测试账号、甚至产品经理的吐槽都一览无余。前阵子某在线教育平台被曝出泄露用户手机号，根源就是source map没删，前端代码里藏着数据库查询逻辑，稍微一推就能构造注入。

怎么查？别只靠人工翻代码。我习惯先跑一遍自动化工具，比如 trufflehog 扫git历史，gitleaks 查提交记录，再配合 LinkFinder 从JS里提取所有URL和路径。手动部分重点看这几个地方：config.js、env.js、webpack.config.js、package.json 里的scripts，还有Nginx配置里的 autoindex on 这种低级错误。有一次我在一个政府网站的子目录下发现 /backup/ 目录直接可列，里面躺着整站源码的zip包，日期是2019年。

查到之后怎么处理？硬编码的凭证必须立刻轮换，别想着改代码就完事——已经泄露的密钥就算删了，攻击者可能早备份了。然后才是清理代码，用环境变量或密钥管理服务替代。source map在生产环境要么关掉，要么上传到Sentry这类平台后删除本地文件。调试接口和目录列表功能，上线前必须用配置强制关闭。

最后说个容易忽略的点：第三方组件。你自查得再干净，引入的npm包或CDN脚本里可能带着敏感信息。去年有个流行的前端埋点库，某个版本把测试环境的写入密钥打进了生产包，几千个网站中招。所以依赖项也要定期用 npm audit 或 retire.js 过一遍。自查不是一劳永逸的事，每次发版前跑一遍脚本，比事后救火强得多。