支付卡行业数据安全标准(PCI DSS)3.1版要求6.6建议，WAF可被部署为漏洞扫描的替代品。而国际信息系统审计协会(ISACA)的“开发运营从业者注意事项”，将WAF包括进了公司减少开支增加灵活性所需考虑的10大管家安全控制措施当中。
如今，很多大中型公司都提供多种WAF解决方案，通常打包DDoS防护、内容分发网络(CDN)、应用交付控制器(ADC)和其他相关服务一起提供。亚马逊Web服务(AWS)最近也启动了自己的WAF。
Gartner预测，到2020年，超过60%的公共Web应用将受到WAF的保护。然而，2015年，Gartner只将一家厂商Imperva作为业界领袖，两家厂商DenyAll和 Positive Technologies 作为远见者，列入了WAF魔力象限图中。所有其他厂商，要么被当做特定领域者，要么就是挑战者。更多的WAF厂商因为没达到入选条件，根本就没在魔力象限图中露脸。

去年，安全研究员马辛·艾哈迈德发表了一份技术白皮书，说明几乎所有流行WAF厂商提供的跨站脚本攻击(XSS)防护都能被规避。在宣布其封闭和开放漏洞奖励项目之前，XSSPosed就几乎每天都在大型网站（包括亚马逊）上公布新的XSS漏洞，这些是见证魔力象限上提到的几乎每个WAF是怎样被安全研究员绕过的绝佳资源。新兴的运行时应用“自防护”(RASP)，也能用对付WAF的类似方法规避掉。
信息安全公司 High-Tech Bridge，最近发布了关于名为ModSecurity的白标开源WAF的研究报告，展示了WAF能够用以修复像“不当访问控制”或“会话固定”这样的复杂漏洞。然而，不幸的是，很多商业厂商甚至提供不了ModSecurity一半的技术能力和灵活性来实现虚拟补丁。
不过，High-Tech Bridge 的研究也指出，ModSecurity的开放Web应用安全防护(OWASP)核心规则集(CRS)，在默认配置下也是可以绕过的，而创建定制规则集可能非常复杂且耗费时间。

为什么今天的WAF防护经常达不到人们的期望，主要原因有五：
1. 部署疏忽、技能缺乏，以及风险缓解优先级的差异。
很多公司单纯是没有足够的技术人才来进行WAF配置的日常维护和支持。这一点也不奇怪，他们只是把WAF弄成检测模式（不封阻任何东西），甚至也不查看日志。
2. 仅仅为了合规才部署。
中小型企业经常是出于应付合规要求才安装WAF。他们才不关心实际的安全，而且明显不会在意WAF维护问题。
3. Web应用发展太快种类太多。
今天，几乎每家公司都有内部或定制Web应用，用不同的编程语言、框架和平台开发。90年代的CGI脚本搭配使用第三方API和Web服务的复杂AJAXWeb应用的情况也不少见。另外，Web开发者几乎每天都要升级更新他们的应用来适应业务需求。很明显，这么一个动态的多样化的环境，即使最好的WAF加上最有能力的工程师，也很难保护周全。
4. 业务优先级压过网络安全。
WAF误封合法网站用户的情况几乎无法避免。通常，在第一起某客户因无法享受服务怒而转投竞争对手的事件进入到管理层视线之后，WAF就绝对会被设置成只检测不动作模式了（至少要到下一次质量体系评定审计）。
5. 无力防护高级Web攻击。

从设计上，WAF就不能防护未知应用逻辑漏洞，或者需要对应用业务逻辑有着透彻了解的漏洞。很少有创新者会尝试使用结合了IP信誉、机器学习和行为检测白名单的增量式规则集来防护此类漏洞。这些东西都需要经过复杂而漫长的学习周期，而且还没那么靠得住。

在企业中部署和维护一个WAF，依然是一项相当复杂的安全控制措施。但WAF可能也是Web应用唯一的预防性安全控制，能大幅降低Web漏洞利用的风险。一个配置良好的WAF，即使是在非常动态且复杂的环境下，也可以防护住大多数常见Web漏洞攻击（比如XSS和SQL注入）。而且，假若出于某种原因无法修复有漏洞的Web应用源代码，或者无法应用厂商发布的补丁程序，WAF虚拟补丁也可以充当救命稻草。
尽管如此，也绝不能将WAF当成应对Web攻击的灵丹妙药，应当总是辅以其他安全控制措施，比如漏洞扫描、开发者安全培训，以及持续监测。
在当今这个数字互联的世界里，网络攻击已经成为“新常态”。没有什么所谓的“灵丹妙药”，更没有包治百病的“银弹”。网络安全工作是一场旅程，起始于关键风险和重要资产的识别，然后再在技术、流程和人员管理之间找到正确的组合。
最后，尽管不足以应对现代Web应用中的复杂安全漏洞，WAF依然是公司内部必要的安全控制措施。