上个月我帮一家电商公司做安全审计，信息泄露发现他们的漏洞用户订单接口把数据库报错信息原封不动地吐给了前端。攻击者只要在参数里加个单引号，复方就能看到完整的信息泄露SQL语句——包括表名、字段名，漏洞甚至数据库账号。复方这种信息泄露漏洞，信息泄露修复起来其实不复杂，漏洞但很多人压根没意识到自己已经“裸奔”了。复方

最直接的信息泄露修法，是漏洞掐断错误信息的输出通道。生产环境里，复方所有数据库异常、信息泄露文件路径、漏洞堆栈追踪，复方一律只记录到服务端日志，返回给用户的统一写成“请求处理失败”。别嫌粗暴，这是最有效的止血手段。我之前见过一个团队，为了调试方便，把详细错误信息直接打到页面上，上线半年都没改——直到被爬虫把整个用户表结构给扒走。

但光堵输出不够，还得堵住源头。绝大多数信息泄露，都是因为接口参数过于信任用户输入。比如那个订单接口，明明只该查当前登录用户的订单，却允许传入任意订单号，结果别人把订单号改成10086，就能看到别人的收货地址。修复方案很简单：在服务端强制绑定当前会话的用户ID，查询条件里加上WHERE user_id = ?，参数化查询，别拼字符串。这条改完，至少能挡掉80%的越权访问。

还有一种泄露渠道容易被忽略——响应报文里的冗余字段。很多后端开发图省事，直接把整个数据库实体序列化返回给前端。实体里有password_hash、internal_remark、created_by这些字段，前端用不上，但攻击者看得到。我遇到过最离谱的一次，某家公司的API把数据库连接串放在一个叫debug_config的字段里，前端页面还正好有个“导出JSON”的功能。修这个，得单独建视图模型（DTO），只返回前端需要的字段，千万别偷懒直接返回实体类。

日志和监控也得跟上。信息泄露往往不是一次性事件，攻击者会反复试探。你在日志里记录所有异常堆栈和完整请求参数，平时没人看，但出事时这就是破案线索。我建议至少把error级别的日志单独存一份，保留90天以上，并且加上敏感字段脱敏——比如手机号中间四位打星号，身份证只留前后各两位。别觉得麻烦，真被刷接口的时候，这些日志能帮你快速定位泄露范围。

最后说个反直觉的细节：修复信息泄露，往往不是加更多安全设备，而是做减法。删掉不必要的调试接口，关掉没用的管理后台，移除代码里写死的测试账号。我审计过一家公司，他们的测试环境居然能通过公网访问，而且用的是跟生产环境一样的数据库密码——这种“信息”泄露，比任何SQL注入都致命。把该关的门关上，比装一百个防火墙都管用。

说到底，信息泄露漏洞的修复方案就三句话：对外藏好错误信息，对内管好参数校验，平时做好日志和权限收敛。别追求花哨的防护技巧，把这三件事做到位，你的系统已经比大多数同行安全了。