app referer校验失败

凌晨两点，校验我盯着崩溃日志里那条referer校验失败，失败差点把手机摔了。校验用户明明从微信里点开的失败链接，后台却判定请求来源非法——这已经不是校验第一次了。

问题出在哪儿？失败大多数app的referer校验逻辑都太“死心眼”。它只认固定的校验域名白名单，比如https://mp.weixin.qq.com。失败可现实是校验，微信内置浏览器会动态拼接参数，失败有时候带个from=singlemessage，校验有时候又多个scene=2。失败你写死一个正则，校验人家改个参数就绕过你。失败更坑的校验是，安卓端某些第三方浏览器会主动剥离referer头，或者干脆发个空的——你的校验逻辑一看到空值就秒拒，用户那边就显示“页面打不开”。

我上次排查一个电商app的案例，用户反馈从百度广告点进来永远跳转失败。抓包一看，百度跳转时先经过一个link.baidu.com的中间页，referer变成了这个中转域名，而不是最终落地页。开发团队当初只校验了baidu.com，没想到中间层多了一级。就这一个细节，广告投放的转化率掉了三成。

别急着骂开发。referer校验本来就是把双刃剑——防的是CSRF和盗链，可它依赖的是客户端主动上报的信息。懂点技术的人用curl随便改个头就能伪造，而普通用户却常被误伤。我见过最离谱的案例，某个金融app强制校验referer必须来自自家官网，结果用户在app内嵌的webview里分享链接到微信，再从微信点回来，referer就变成了微信的域名，直接被拦截。用户以为app坏了，其实是被自己的安全策略锁死了。

怎么破？我自己的经验是分级处理。敏感操作（比如支付、改密码）做严格校验，但普通页面跳转只做宽松过滤——只要referer不是明显的外部恶意域名，就放行。另一个笨办法是增加容错：遇到空referer或校验失败时，不要直接拒绝，而是弹一个二次确认页，让用户手动操作。虽然多一步，但至少不会把用户堵死在门外。

对了，别忘了测试那些“非主流”场景。我踩过一个坑：iOS的“通用链接”功能在冷启动时会先唤起app，再通过系统传递referer，那个值长得跟普通请求完全不一样。当时测试组只测了热启动，线上就炸了。现在我的规则里专门加了一条——凡是app内部发起的请求，referer校验直接跳过，因为攻击者根本进不了app进程。

说真的，referer校验失败这事，八成是设计时没想清楚“你防的是谁”。如果防的是外部爬虫，那校验IP和请求频率比referer管用；如果防的是恶意跳转，那不如直接校验签名。把宝全押在referer上，就像用纸糊的盾牌挡箭——看着严实，一戳就破。下次再看到这条报错，先问自己一句：这校验到底拦住了谁，又误伤了谁？