安全服务说自己比防火墙多挡 74% 的利用尝试，这种对比怎么掂量

安全服务宣称自己比防火墙多挡 74% 的利用尝试，这种对比数据该怎么掂量？先别接受这个数字，先问三个问题：基线是哪一类产品、分母是哪一段时间哪种攻击样本、以及你自己站点能不能用日志复核出同向结论。厂商原话是相对主流 Web 应用防火墙可多防止 74% 的漏洞被利用，这个说法本身带着限定语 up to，读的时候要把限定语一起记住。

基线模糊时数字没有意义

对比数字的第一处信息量在基线上。同类说法里最常见的做法是拿一个通用边界设备当对照：防火墙工作在请求进入之前，它看到的路径与参数是通用的，而站点级防护知道具体哪个扩展、哪个版本存在已知缺陷。基线不同，差值就不同。看到百分比时先确认它在跟谁比——跟什么都没配的裸站点比，任何方案都能报出很高的数字。

分母决定这个数字好不好看

第二处是统计范围。分母如果是利用尝试次数，那么只要拦截掉自动化扫描器的高频重复请求，比例就能显著抬升；分母如果是成功利用的事件数，数字通常要小得多，但它才对应真实损失。同一家产品的两份材料里出现两个不同百分比，多半是分母换了而不是能力变了。评估时优先问：这个比例里，被算作成功拦截的判定标准是什么。

用日志复核出一个同向结论

复核不需要新工具，需要把已有日志按三件事整理：一是攻击面分布，哪些路径被反复试探，集中还是分散；二是拦截层级，请求是在边缘被挡掉、在应用校验时被拒、还是根本没被识别；三是结果，被试探的路径在你的站点上是否真的存在。如果集中试探来自第三方扩展的路径而你并未安装它们，那这类防护带来的收益本来就偏低，任何对比数字都与你的实际风险无关。

防线位置比百分比重要

真正要评估的是防线的层次是否齐备，而不是单一数字。代码层看认证与输入处理，SQL 注入与 XSS 的防线必须落在应用内部，例如 JWT 认证加上参数约束，防火墙无法替应用完成这一层；内容层看发布前有没有敏感词过滤与关键词替换、内容审核要不要人工过一道；表单层看评论区与提交口是否接入验证码或 reCAPTCHA；取走环节看内容被批量采集时是否失去可用性，干扰码与防采集起的就是这一层作用；接口面还要看高危操作的默认状态，备份、升级、多站点这类全站级动作应当按域默认关闭，需要显式开启。

把这五层列成一张自查表，比记住一个百分比有用得多：每层写清现有措施、缺失项与验证方式，缺哪层补哪层。百分比数字只能提示防护思路的差异——边界拦截与站点级纵深不是替代关系，通常要同时存在。

什么时候该重新评估

三类信号出现时值得重跑一次评估：站点换过技术栈或装了新的第三方模块；同类系统披露了高危漏洞而你的分支不在修复范围；被试探的日志量突然上升且路径集中。评估的产出不是换一个供应商，而是知道自己现在的防线在哪一层断掉。

常见问题

厂商对比数据完全不采信吗？ 采信它的方向而不是数字，它可以提示边界防护与站点级防护的差异，具体收益仍以自己站点的日志复核为准。

装了防火墙还要做内置防线吗？ 要。注入与跨站脚本的防线在应用代码里，认证与内容过滤也无法由边界设备代做，两者是叠加关系。

多久复核一次防线清单？ 建议随版本升级复核，另外每年至少做一次全量演练，重点验证备份恢复与高危域的默认关闭状态。