所有应用程序都会使用 API（调用内核、软件开发工具包、加密库和 SOAP，仅举几例）— 它们并不是什么新鲜事物。如今供应商所称的“API 安全”指的是这些 API 的一个子集 — — 即通过网络公开的 API。就其本质而言，这些通过网络公开的 API 可实现信息自由流动和软件组件之间交互。通过将端点暴露在公共、云端和私有网络中，攻击者有了新的机会来攻击您系统的这些组件。

我们已经看到几家知名公司（USPS、  T-Mobile和 Salesforce 等）发生了引人关注的漏洞，这些漏洞源于暴露或使用不安全的 API 端点。这就引出了一个问题：您如何知道您的软件安全计划是否解决了确保使用和生成的 API 安全所需的控制？要回答这个问题，首先需要定义“API 安全”。

“API 安全”到底是什么？

API 安全是对贵组织生产和使用的网络公开 API 的保护。当然，这意味着使用与 API 相关的常见安全控制：速率限制以及用户、服务和请求的身份验证和授权。这还意味着了解数据来源，并在查看组合系统时，在设计或审查讨论期间准确寻找上下文。对于领导者来说，这意味着应用程序安全程序会在适当的时间捕获并应用活动到软件公开或使用 API。强大的 API 安全性不仅仅是购买一些新工具，它源于安全文化，涉及整个软件安全计划的活动。

解决 API 安全问题

微服务架构等流行软件开发趋势已将与 SSI 相关的软件单元从“应用程序”（或整体）转变为许多公开 API 的子组件，这些子组件具有自己的生命周期和要遵守的契约，以及必须存在的安全控制。软件安全主管可以在以下领域找到改进的机会：

设计 API

API 用于 前端客户端 （胖客户端、浏览器）和后端系统之间，以及后端组件之间。更复杂的是，单个 API 端点最终可能会同时处理前端和后端请求。当单个 API 端点暴露给各种已知和未知的调用者（由网关或负载平衡器使用、编写或包装到上游）时，很难确定单个 API 端点必须执行哪些安全控制。应用程序安全领导者可以做出的一个决定是推动 API 明确记录提供商和消费者承担的安全责任。

架构师还面临着识别 API 的交叉问题。安全主管应关注那些安全工作，例如统一访问控制，以及那些接近业务逻辑的工作，例如统一客户身份。

安全控制

关于安全控制，API 安全性中有几个抽象级别：业务逻辑内的控制（针对滥用故事的保护）、保护业务逻辑的控制（身份验证和授权），以及最后由架构启用或定义的架构安全控制（API 网关、微分段）。

在 API 安全环境下，架构决策支持的安全控制对于应用程序开发来说相对较新。除了应用于业务逻辑的安全控制之外，这些控制还涉及速度检查、身份验证和授权决策等问题。我们还想知道如何最好地隔离 API 集群，其中重要的安全控制可以通过网关启用。例如，微分段是否可行？服务网格 提供的控制有多有效？

一些架构决策寻求提供瓶颈，使安全架构师能够更深入地了解这些分布式系统。虽然一些架构决策要求采用集中管理的方法，但另一些则支持端点强制方法。其他则是混战。领导者还必须应对并考虑来自进入市场的供应商的主张，这些供应商推出了新的应用程序防火墙和数据丢失预防 (DLP) 机制。

当然，我们推荐 威胁建模。应用程序安全主管必须开始识别各种 API（第一方、第三方、客户端或消费者）的风险、每个 API 端点的关键控制、API 密集型架构（如微服务）带来的问题的可接受解决方案，以及是否将供应商声明作为风险管理计划的一部分.

存货

领导者需要了解组织的 API 足迹；衡量使用流程和工具覆盖该足迹的努力；跟踪、记录和优先考虑正在进行的安全活动；并为各种类型的安全分析提供丰富的背景信息。当我们与程序所有者讨论 API 安全性时，我们经常发现现有的库存解决方案无法提供这种洞察力。程序所有者可以仔细考虑是否可以调整现有的库存解决方案，或者是否必须采用新的解决方案。

用准确的信息填充您的库存则完全是另一回事。组织可以从开发团队获取一些信息，但他们应该投资于发现流程逃逸。这些信息的来源包括部署在客户端和服务代码库（或二进制文件或实时实例）上的传感器、网络检查、OSINT 技术和纯黑盒发现。最终，您应该能够将发现传感器的结果纳入您的库存并对您一无所知的 API 采取行动。

安全测试

如今，安全测试与洞察上游软件安全实践的有效性一样重要。API 的安全测试为手动、自动和混合活动带来了新的挑战。上下文就是这样一个差距；如果测试人员收到了 API，但缺乏形成输入或直观威胁模型的能力，他们将无法找到挑战 SSI 改进的高价值问题类型。当然，工具的表现也好不到哪里去。

静态分析工具可以有效识别特定于语言的软件安全问题或易于理解的注入攻击类别，并且仍然对 API 密集型代码库有效，但前提是这些工具还模拟用于公开这些 API 路由的库和平台。静态代码分析工具在发现业务逻辑缺陷方面从来都不是很好。密集型 API 项目需要跨代码库推理能力，这进一步加剧了这一差距。静态分析工具仍然是工具箱中的重要工具，但领导者应该评估工具在使用其组织最流行的 API 平台编写的代码中查找缺陷的能力。幸运的是，采用静态分析方法来推动采用安全控制（如使用身份验证和授权库）的组织会发现他们的策略仍然适用于 API 安全。

可以生成 API 覆盖范围的典型 动态分析方法 包括使用客户端（或工具）进行测试、使用行为测试和使用规范进行测试。这里的解决方案不是构建一个测试工具并强迫开发团队使用测试工具，而是支持各种可能的测试安排。领导者应该寻找激励项目采用提高可测试性的做法的方法；成本和速度是两个很好的切入点。

现代应用程序和系统依赖于通过各种公共和私有网络公开的复杂 API 系统。我们可以采取一些步骤来了解这些变化如何影响我们软件安全计划的各个要素，并确保在正确的时间和地点将安全性融入到公开或使用 API 的软件中。

文章来源：Are you ready for API security?