凌晨两点十七分，代码某电商平台的漏洞网关日志里突然涌进三千条畸形请求。每条请求的未对报头里，User-Agent字段都被替换成了十六进制转义序列——安全团队盯了半个月的请求漏洞，终于被攻击者摸到了门。信息校验

问题出在代码里那句看似无害的进行getHeader("X-Forwarded-For")。开发图省事，代码直接拿这个值当IP用，漏洞压根没校验报头里塞的未对是不是合法字符串。攻击者往里填了段精心构造的请求payload，网关解析时直接崩了，信息校验内存里残留的进行数据被顺势拖走。事后复盘，代码漏洞修复只花了一行正则，漏洞但被拖走的未对用户隐私已经挂在暗网上明码标价。

类似的事故我见过太多。去年有个做智能硬件的团队，设备固件里有个HTTP服务，报头Content-Length没做范围检查。黑客发个Content-Length: -1的请求，服务端直接分配了负数的内存缓冲区——这在C语言里等于把整个堆栈拱手让人。更讽刺的是，他们产品说明书上还印着“军工级加密”。

报头校验这事，说白了就是“进门先查身份证”。但很多开发者觉得，报头是客户端发来的，能有什么坏心思？坏心思多了去了。Host字段能注入恶意域名，Cookie字段能塞超长字符串撑爆内存，Referer字段能藏SQL注入语句。哪怕是最不起眼的Accept-Language，攻击者都能用畸形编码绕过WAF。

我翻过某大厂的开源框架源码，发现他们对报头的处理逻辑竟然是“先信任，后检测”。所有请求进来先过一遍白名单，但白名单只过滤了方法和路径，报头字段的key和value长度上限压根没设。结果呢？生产环境里真有人发了单个报头超过64KB的请求，直接把Nginx的buffer打满，后面的正常请求全被堵死。

有人可能要杠：HTTP协议规范里不是写了报头格式吗？规范是写了，但规范管不住实现。你永远猜不到客户端会发什么鬼东西过来——有人用Python requests库发二进制报头，有人用curl塞emoji，还有人直接拿原始socket拼了个不带冒号的报头行。这些情况，服务端代码但凡少一道校验，就是一道口子。

最要命的是，报头校验缺失往往不是单独存在的。它常和日志注入、缓存投毒、请求走私这些漏洞手拉手出现。攻击者先通过未校验的X-Forwarded-Host把恶意域名写进日志，再诱导管理员去查看日志页面——XSS就来了。一套组合拳下来，服务器权限就跟纸糊的一样。

说句得罪人的话，不少团队把报头校验当成“防御性编程”的边角料，觉得加了是锦上添花，不加也不影响主流程。可真等出了事，光排查日志就要耗掉整个通宵。与其那时候手忙脚乱，不如在写@RequestHeader注解时多敲几行校验代码。这活儿不酷，但能保命。

眼下正值AI生成代码泛滥的时候，很多新手直接拿大模型吐出来的代码往生产环境怼。模型可不会提醒你“这个报头字段没校验”——它只会按你给的prompt功能把逻辑跑通。真要指望AI写出滴水不漏的报头处理逻辑，不如先指望自己把需求文档里的安全条款读明白。