网站敏感信息

去年秋天，网站我在一个做电商的敏感朋友公司里坐着，他忽然收到一条告警：有人在爬他们商品详情页，信息频率不高，网站但持续了三天。敏感技术团队一开始没当回事，信息觉得不过是网站比价软件。直到风控同事发现，敏感那个IP抓走的信息页面里，包含了供应商联系方式、网站内部库存编码，敏感甚至还有一段被误嵌进前端的信息采购价备注。三天，网站足够把核心供应链信息搬空。敏感

网站敏感信息从来不只是信息“密码泄露”四个字能概括的。它藏得比大多数人想的要深，也要散。前端源码里的注释、接口返回的冗余字段、日志文件里没擦干净的手机号、测试环境忘了关的调试页面——每一样单独看都不致命，拼在一起就是一张完整的底牌。

我见过最离谱的一个案例，是一家在线教育平台。他们的课程视频播放页，URL里带了一个参数叫 is_trial=1。改成0，就能看完整付费内容。这个参数在前端被混淆过，但接口返回的JSON里明明白白写着 "trial": false。开发觉得前端已经处理了，后端没必要再校验。结果就是，任何人抓一次包，就能白嫖全部课程。这不是技术漏洞，这是思维漏洞——把“用户看不见”当成了“用户拿不到”。

另一个常被忽略的地方是错误信息。登录失败时返回“用户名不存在”还是“密码错误”，这中间的差别，攻击者拿来就能做用户枚举。注册接口如果对已存在的手机号返回“该号码已注册”，那批量试号就是顺手的事。很多团队在开发阶段为了调试方便，把数据库报错直接抛到前端，表名、字段名、甚至SQL片段全露出来。上线前忘了关，等于把后门钥匙挂在门把手上。

还有一类敏感信息，不在代码里，在人身上。客服系统里能查到的用户收货地址、售后工单里附带的身份证照片、内部IM里传的合同扫描件。这些数据一旦被内部人员批量导出，或者因为某个第三方插件申请了过宽的权限，泄露路径比外部攻击要短得多。技术防护做得再厚，也挡不住一个拥有合法账号的人把数据复制走。

说回我朋友那件事。后来他们复盘，发现爬虫之所以能拿到采购价，是因为一个已经离职的前端在打包配置里留了 sourceMap: true。生产环境的JS被完整还原，注释里写着“临时写死，上线前删”。没人删。那个文件在CDN上躺了八个月。

处理网站敏感信息，核心不是买多贵的WAF，也不是堆多少条正则过滤。先做一件事：把所有对外暴露的东西列出来——页面、接口、响应头、错误码、静态资源、第三方脚本。然后逐个问：这个字段用户真的需要看到吗？这个报错真的需要这么详细吗？这个调试开关真的不能关吗？大部分泄露，答案都是“其实不需要”。

剩下的小部分，靠流程。上线前的安全检查清单里，加上“确认sourceMap关闭”“确认调试接口下线”“确认错误信息脱敏”这三条，能拦住八成低级事故。再往上，是权限最小化和数据分级。不是所有员工都需要看到完整手机号，不是所有接口都需要返回用户全量信息。能拆开的拆开，能掩码的掩码，能后端校验的绝不放前端。

最后说一句可能不太中听的话：很多公司对敏感信息的重视，是在出事之后才建立的。在那之前，他们更愿意把精力花在功能迭代上。这可以理解，但代价往往比想象中高。一条泄露的采购价，可能让供应商集体涨价；一个没关的调试接口，可能让竞品把你的用户库爬个干净。技术债里，安全债的利息最贵。