没有Web应用防火墙(WAF)，很难想象应用的安全性。在过去的20年里，WAF一直是应用安全堆栈的重要组成部分，帮助组织保护其敏感数据和事务免受攻击。WAF在应用程序前部署了先进的安全解决方案，通过分析流量元数据和广泛使用的预配置策略，防止已知漏洞独立保护应用程序。WAF是一种通用的安全解决方案，以同样的方式保护任何web应用程序，而不考虑应用程序的功能和用途。

但是webAPI不同于web应用。同样的野兽，不同的动物。对应用程序有效的东西不足以保护API。事实上，当涉及到API的保护时，WAF的优势是它们最大的缺点。WAF和API安全。WAF的有效性取决于其执行政策。现代WAF(又称NextGenWAF)一旦完成费力的手动配置过程，就具有自动创建策略的先进功能。

近年来，WAF解决方案开始包括对API滥用的保护措施。这些保护通常包括输入验和内容威胁检测，以解决几种常见的技术API操作形式。为了启用这些保护，WAF通过接受API模式(如OpenAPI规范(fkaSwager)来创建特殊策略。

虽然这些保护是有效的，但它们依赖于提前准确的模式。然而，现实是，这种先决条件往往不能满足，组织难以跟上文件的进度。结果如何？过时、不完整或不准确的模式认为WAF保护是无关和嘈杂的。此外，WAF需要大量的调整和维护，因此API的多样性和速度使其无法保持领先地位。安全团队通常不知道API的变化，甚至组织必须从哪些API开始。

API威胁态势。

WAF位于应用程序前面，可以使用模式进行输入验证(1)，但通常对功能攻击(2)和公开可用的恶意API(3)仍然无效。但也许最重要的是，即使是最好的模式也只能描述数据的结构。它们为API调用提供技术指导和标准，但不涵盖其使用方法和目的。业务逻辑没有记录。这就是为什么模式可以用于防御技术攻击，但在防御功能攻击中几乎没有用处。

案例研究：功能攻击。简而言之，功能攻击旨在破坏应用程序的预期流。在执行功能攻击时，攻击者会找到操纵API的方法来访问受限的敏感资源，或诱导API执行不应执行的操作。通常，功能攻击利用API设计和实现中的缺陷。考虑以下通过项目API窃取敏感数据的案例：在项目服务的正常使用中，用户作为注册过程的一部分，输入电话号码，然后与其投资账户相关联。各种数据对象之间存在1:1或1:n的关系，反映在常规用户行为中。