劝阻使用 Web 应用防火墙
Web 应用防火墙（WAF）常被批评为昂贵、会引入延迟、制造虚假的安全感、容易被有决心的攻击者绕过，而且经常只是为了满足 PCI-DSS 或 HIPAA 之类的合规勾选项而部署。评论者认为，安全设计、参数化查询、静态分析以及服务的正确隔离通常能提供更好的保护，而调校不佳的 WAF 甚至会引入新的漏洞或破坏合法流量。另一些人则反驳说，WAF 作为纵深防御仍有作用：处理大流量攻击、保护遗留或第三方应用、为新威胁提供快速的“虚拟补丁”，并过滤大量自动化垃圾流量。
合规、审计与打勾式安全
- 许多部署主要是为了满足 PCI-DSS、HIPAA 或内部检查清单；审计人员往往只验证是否存在 WAF，而不是其是否有效。
- 有人指出 PCI-DSS 允许替代方案（例如持续 DAST），但 WAF + OWASP 规则通常是最容易拿出来作为证据的方式。
- 这导致了“假装有 WAF”的情况：只有极少或完全没有拦截规则，只是为了勾选方框。
有效性、绕过与作用范围
- 批评者认为，基于正则/签名的 WAF 很容易被具备中等技能的攻击者绕过，尤其是通用云服务。
- 也有人反驳说，WAF 在实践中确实会阻止真实攻击（例如逃过代码审查和工具检测的 SQL 注入），并通过过滤自动扫描和明显的利用载荷来提高攻击门槛。
- 还有人强调，WAF 不是灵丹妙药，而是纵深防御的一部分；单独依赖它们很危险。
性能与攻击面
- 有人指出会带来显著的延迟和吞吐损失，尤其是 ModSecurity 风格的引擎，并提到设计良好的应用返回 404 的速度可能比 WAF 检查还快。
- 也有人担心，WAF 本身会增加一个很大的、内存不安全、面向互联网的代码库，并带来新的配置错误风险；极端情况下，它们甚至曾成为入侵途径。
运维与组织现实
- 企业级 WAF（例如 Imperva 级别）可能需要大量调优、人员投入和持续的规则维护；很多最终都变成了“装上就不管”。
- 另一些人则认为，云 WAF 足够容易管理，可以兼职维护，并且对基础的机器人过滤、IP 信誉和 L7 速率限制很有用。
- AppSec 团队通常能比应用或 Web 服务器配置更快地修改 WAF 规则，这使得 WAF 很适合做“虚拟补丁”（例如 Log4j 载荷、阻止特定端点）。
误报与用户影响
- 多个例子显示合法流量被拦截：OpenID 重定向、地址中的常见词如 “Union”、标准框架行为。
- 过重的默认规则集（例如“全部启用”）被认为尤其有问题，有时还会促使人们采取不安全的变通办法。
替代方案与补充方案
- 强调安全的应用设计：参数化 SQL、静态分析、严格的 API 类型、进程隔离、最小权限访问。
- 有人建议，基础的网络层阻断、IP 黑名单，以及 API 网关/前端路由器，作为更简单或更透明的替代方案或补充方案。