去年某电商平台被曝出一起数据泄露，敏感起因简单得让人无语——后台订单查询接口没做权限校验，信息泄露任何人修改URL里的漏洞订单ID就能看到别人的收货地址、电话和购买记录。敏感安全团队复盘时发现，信息泄露这个接口三年前就存在，漏洞只是敏感没人想到去测。敏感信息泄露漏洞往往就是信息泄露这样，不是漏洞攻击者多高明，而是敏感防守方太疏忽。

什么叫敏感信息泄露？信息泄露说白了，就是漏洞系统把不该给用户看的东西给出去了。身份证号、敏感手机号、信息泄露银行卡、漏洞密码哈希、API密钥、内部IP、数据库报错信息——这些都属于敏感信息。它不一定直接导致系统被拿下，但泄露出去的东西可以给后续攻击铺路。比如拿到内部员工邮箱列表，钓鱼成功率翻倍；拿到数据库报错里的表名和字段，SQL注入就有的放矢了。

OWASP Top 10里专门有一类叫“敏感数据暴露”，但实际渗透测试中，我发现它比SQL注入和XSS更普遍。原因不复杂：注入和跨站脚本有明确的payload和修复方案，开发者多少有防范意识。敏感信息泄露不一样，它藏在细节里。一个前端打包后的JS文件里硬编码了云存储的AccessKey，一个测试环境忘记关的Swagger文档，一个返回体里带了完整用户对象的API——这些在代码审查时很容易被忽略，因为功能“跑通了”。

我印象最深的一次测试，目标是一个政务系统。登录页面看起来很正常，但查看页面源码时发现注释里写着一行测试账号：admin/123456。试了一下，直接进后台。后台里有个“用户管理”模块，点进去，所有公民的姓名、身份证号、住址一览无余。从发现到拿到全量数据，不到十分钟。这个案例里，漏洞链条的起点就是一条HTML注释。

再说个更隐蔽的。某次对一家创业公司做安全评估，他们的App接口返回用户信息时，除了昵称和头像，还带了一个字段叫“internal_notes”。这个字段本意是给客服看的备注，但接口没有做字段过滤，普通用户也能拿到。里面写了什么？有用户被标记为“恶意投诉惯犯”，有用户被备注“疑似竞品卧底”。这些信息一旦被爬取，足够写一篇引爆舆论的报道。开发者的解释是“方便调试，忘了删”。

怎么防？很多人第一反应是上加密、上脱敏。方向对，但不够。敏感信息泄露的核心问题是“暴露面”失控。我的经验是三条：第一，默认不返回。API设计时，响应体只包含当前场景必需的字段，不要图省事直接序列化整个对象。第二，权限校验下沉到数据层。不要只在Controller层判断“用户是否登录”，要判断“这个用户是否有权访问这条数据”。第三，把敏感信息扫描纳入CI/CD。用工具自动扫代码里的硬编码密钥、日志里的明文密码、前端打包产物里的内部地址。人会忘，机器不会。

还有一点容易被忽略：错误处理。很多系统抛出异常时，直接把堆栈信息返回给前端。堆栈里可能有数据库连接字符串、文件路径、依赖库版本。攻击者拿到这些，等于拿到了系统地图。正确的做法是统一异常处理，对外只返回“系统繁忙，请稍后重试”，详细信息写进内部日志。

最后说个观察。敏感信息泄露漏洞的修复成本通常很低——加个字段过滤、改个权限判断、删行注释，可能就几行代码。但发现成本很高，因为它不像SQL注入那样有明显的攻击特征，也不像XSS那样能弹窗证明。它需要测试者有一种“好奇且多疑”的心态：这个接口返回的字段是不是太多了？这个页面源码里有没有不该有的东西？这个报错信息是不是太详细了？安全这行，很多时候不是比谁技术强，而是比谁更细心。