摘要：API为各地公司正在进行的数字转型计划提供了动力。这就是董事会会议室对改善数字体验的需求，在过去几年中，供应商看到了跨平台API流量的爆炸式增长。谷歌的API平台服务Apigee最近指出，API流量增加了46%，达到2.2万亿次调用。

API为各地公司正在进行的数字转型计划提供了动力。这就是董事会会议室对改善数字体验的需求，在过去几年中，供应商看到了跨平台API流量的爆炸式增长。谷歌的API平台服务Apigee最近指出，API流量增加了46%，达到2.2万亿次调用。
　　
　　不幸的是，API消耗量的增加反映了对API基础设施的攻击的增长。例如，包括LinkedIn、Peloton和Facebook在内的知名品牌由于其API受到攻击而遭受数据泄露。这一趋势将继续下去；加特纳估计，API滥用将从明年罕见的移动到最频繁的攻击向量，导致企业Web应用程序数据泄露的风险增加。
　　
　　为什么会出现API安全问题
　　
　　三个关键模式解释了API安全问题如此频繁的原因：
　　
　　应用程序开发正在发生变化：应用程序是以单一方式使用自行开发的库构建的，这已经有一段时间了。在这些场景中，服务器端层控制逻辑，保护所有数据，并确定哪些可以和哪些不可以向客户端公开。使用基于API的体系结构，应用程序由数百个内部和外部服务组成。控制逻辑主要发生在客户端，如果直接调用API，则完全忽略控制逻辑。
　　
　　开发团队比以往任何时候都更加敏捷：开发人员可以使用多种语言的丰富开发框架、功能强大的IDE和许多可供使用的开源和商业工具来提高生产力。我们从每六个月发布一次应用程序到每天发布几次。另一方面，应用程序安全团队仍然主要依赖手动过程来测试API。
　　
　　安全性被认为太晚了：开发团队首先关注的是交付功能。在大多数公司，安全不是主要目标；相反，这是开发过程中的一个强制性（通常令人恐惧！）瓶颈。检查安全漏洞有时被认为是单调乏味的，分析工具会产生数百个误报，供开发人员进行梳理。
　　
　　这三个问题形成了一个爆炸性的组合：以疯狂的速度交付的API不断增加，再加上由AppSec团队驱动的手动流程，开发人员的数量大大超过了AppSec团队。
　　
　　保护数据，而不是周长
　　
　　每次一个企业公开一个API时，他们实际上是在其公司外围“打一个洞”来公开数据。
　　
　　这意味着应用程序安全的重点必须从保护组织的外围环境转移到保护存储和访问的数据。传统的应用程序安全解决方案，如通常部署在边缘的web应用程序防火墙（WAF），不再是保护现代体系结构的最佳方案。
　　
　　阻止API攻击：一切都与上下文有关
　　
　　工具需要上下文信息来决定阻止API通信。例如，对API的几种典型攻击涉及使用不正确的动词（即调用GET/tokens而不是POST/tokens）或操纵数据本身（例如通过批量分配或泄漏数据注入数据）。对于WAF，这些调用只是有效的HTTP调用。WAF没有上下文来决定POST是好的，GET不是，或者/tokens有效，而/admin/tokens无效。
　　
　　上下文可以是静态的，也可以是动态的（例如，基于流量构建），但在任何情况下，工具都需要上下文来做出适当的决策。上下文定义了有效的单个调用、所需的安全设置、授权规则、有效的调用工作流和通过API的数据流。上下文信息可以在测试或执行时使用。
　　
　　如果没有上下文，工具需要求助于消极的安全模型，因为它们没有关于流量的信息，所以您唯一的解决方案是通过规则和模式描述您认为不可接受的内容。随着新漏洞的出现，需要编写新的规则。
　　
　　设计时的建筑环境
　　
　　幸运的是，有了API，我们可以用事实上的标准（如OpenAPI或AsyncAPI）来描述API契约。更好的是，我们可以在编写代码之前，在设计时这样做。
　　
　　API契约成为测试API安全性所需的上下文的关键部分，但对于在运行时保护API也是至关重要的。它支持一种积极的安全模型方法，这一直是安全领域的目标。如果您知道流量必须是什么，您可以拒绝访问除预期流量之外的所有内容，并且不需要手动构建规则来捕获坏流量，也不需要利用机器学习等技术来猜测流量应该是什么。
　　
　　机器可读的API描述还可以实现API生命周期每个步骤的自动化，包括合同的自动化分析、自动化功能测试、自动化数据验证和改进的自动化安全测试。这意味着应用程序安全团队可以专注于复杂的笔测试场景，并将其扩展到开发团队的敏捷级别。
　　
　　准备保护，准备胜利
　　
　　我们已经看到，安全从业人员正试图利用传统上用于保护应用程序并对其进行调整以保护API的现有技术。不幸的是，这些解决方案基于消极的安全模型，并且每个新API都代表了进入公司系统的潜在唯一攻击路径，因此这些解决方案无法扩展以应对挑战。
　　
　　新一代API安全解决方案已经出现，旨在解决保护API的正面和负面安全模型方法。作为决策过程的一部分，安全官员需要决定他们的最终目标是什么。它是将安全性嵌入API生命周期（从设计到生产）的一种方法吗？还是在运行时实现补丁以解决已知问题？还是两者兼而有之？可以肯定的是，随着不断增加的API攻击表面，安全实践者需要仔细考虑他们的API安全需求，并确保所选择的解决方案与他们今天和明天所采用的安全姿态的策略相一致。
　　
　　编辑：Harris