用户数据被拖库这件事，网站往往不是个人黑客多厉害，而是信息泄露后台某个接口忘了加权限校验。上个月我们站被曝出手机号可被批量遍历，整改根源就是报告注册接口返回了完整用户对象，连身份证前六位都带出来了。网站测试同学用Burp跑了一遍，个人两万条记录，信息泄露前后不到三分钟。整改

问题出在三个地方。报告第一，网站API响应做了全字段序列化，个人开发图省事直接返回User实体。信息泄露第二，整改日志里打印了请求参数，报告包含明文密码，运维把日志同步到了ELK，谁都能搜。第三，老版本App的登录接口还在用HTTP，没有强制跳转HTTPS。这三件事叠在一起，等于把门钥匙插在锁上还贴了张纸条告诉别人门在哪。

修复从接口层开始。所有返回用户信息的接口，一律走DTO，字段白名单控制。手机号中间四位掩码，邮箱只留首字母和域名。这个改动涉及十七个Controller，测试回归了两轮，发现三个前端页面依赖完整手机号做展示，一并改了。日志脱敏用Logback的PatternLayout，正则替换掉手机号、身份证、银行卡号。密码字段直接不打印。ELK那边把历史索引删了，重新配了采集规则。

HTTPS的事折腾最久。老版本App还有八千多活跃用户，强制跳转会导致他们无法登录。最后的方案是服务端兼容HTTP，但返回一个升级提示，同时把登录接口的token有效期从七天压到一天。产品那边配合推了弹窗，引导用户去应用商店更新。两周后HTTP流量从日均一万二降到了三百以下，可以接受。

数据库层面做了两件事。用户表的敏感字段用AES加密存储，密钥走KMS托管，应用启动时拉取。另外加了一张操作日志表，谁在什么时候查了哪个用户的敏感信息，全部留痕。这个表只允许写入，不允许删除，DBA也没有权限。查询接口加了频率限制，单账号每分钟超过五次就触发告警。

整改过程中发现一个有意思的事。我们以为最危险的是外部攻击，其实内部接口的越权调用更频繁。有个离职员工账号没及时禁用，在测试环境跑了爬虫，把用户昵称和头像全抓了一遍。虽然不涉及敏感信息，但暴露了权限回收流程的漏洞。现在离职流程里加了一步，HR系统触发后自动调用IAM接口禁用所有关联账号，延迟不超过十分钟。

安全这事没有一劳永逸。上周又发现一个商品评论接口，返回的JSON里带了用户ID，虽然没直接暴露手机号，但结合另一个接口的漏洞可以关联出完整信息。已经修了，但说明一个问题：开发在写接口的时候，脑子里没有“最小必要”这根弦。后面的做法是把安全评审塞进需求阶段，每个涉及用户数据的接口必须过一遍checklist，不通过不给排期。

现在回头看，这次泄露没有造成大规模诈骗或骚扰，算是运气好。但运气不能当防线用。接下来三个月，计划把全站接口做一次自动化扫描，用OpenAPI文档生成测试用例，重点查越权、遍历和敏感信息泄露。工具用现成的，关键是把流程跑通，让开发养成习惯。毕竟代码是人写的，漏洞也是人留的，指望工具解决所有问题不现实。