使用第三方API的6个潜在风险

想象一下，你正在一条长路上开车，来到一条隧道，这条隧道可以让你节省几个小时的路程时间。你把车停在护栏前，说：“嘿，我可以从这里过去吗？”

“当然可以！”服务员回答道，“我们会把您的车装到那辆卡车的后面，然后我会开过去，在另一边和您会合。”您会在不检查服务员的驾驶证、卡车状况或他们是否有保险的情况下把钥匙交给服务员吗？

这个比喻并不微妙，但本质上这就是许多开发人员在注册并开始使用第三方 API时没有先进行审查时所做的事情。

根据 Gartner 的 2024 年 API 战略调查，82% 的受访者在其组织内使用 API，而高达 71% 的受访者正在使用第三方（SaaS 供应商）提供的 API。如果没有采取正确的措施来确保安全实施，这可能会成为一个问题。

下面，我们将探讨第三方 API 增长背后的一些动机因素、不谨慎使用它们可能导致的问题，以及减轻这些风险的一些方法。

1. 盲目信任来自服务的数据

现在，几乎四分之三的组织都或多或少地依赖第三方 API。随着各家公司纷纷将生成式 AI 集成到产品中（OpenAI 的 API 等产品推动了这一进程），我们预计上述 71% 的数字将进一步上升。

问题在于，随着某些 API 成为事实上的现状，我们可能倾向于毫无疑问地信任它们返回的数据。这个问题不仅限于与 genAI 相关的 API（它本身就以制作可疑内容而闻名），还延伸到那些以前被认为是“黄金标准”的 API。

举个例子，最近有一波抱怨说谷歌地图越来越糟糕。他们的 API 已被 Domino’s、Uber 和数百万其他组织使用。尽管有些人对路线选择和数据新鲜度表示担忧，但公司仍在蜂拥而至。无论其提供商的知名度有多高，我们都不应假设 API 是万无一失的。

在最近一篇关于使用生成式 AI 增强产品功能的文章中，我们提到了加拿大航空被迫接受聊天机器人承诺的折扣。加拿大法院裁定，聊天机器人不能作为单独的法律实体承担责任，如果您打算在自己的产品中贴牌 API 驱动的 genAI 产品，这一点至关重要。

事实上，OWASP 将对 LLM 的过度依赖列入了LLM 申请的十大因素中。根据 OWASP 的说法，“过度依赖 LLM 且缺乏监督的系统或人员可能会因 LLM 生成的不正确或不适当内容而面临错误信息、沟通不畅、法律问题和安全漏洞。”

虽然这并不意味着您应该完全忽视genAI API可以增加的价值，但它应该是整个实施和评估过程中的一个重要考虑因素。

谈到 API 的不安全使用，OWASP认为，一些开发人员可能过于信任从第三方 API 收到的数据。他们甚至可能因此采用较弱的安全标准，尤其是在使用成熟的 API 的情况下。

语法和语义输入验证可以减少 SQL 注入和其他攻击的影响。这样做可能涉及验证结构化字段的语法或值的上下文正确性。无论如何，在处理来自第三方 API 的数据时都应考虑输入验证。

我们最近写了一篇关于尝试破解您自己的 API 的文章。考虑您的产品与之交互的外部 API 和数据源绝对应该成为此API 安全测试过程的一部分。还值得看看 API 提供商为保护其服务而采取的其他措施。

许多 API 提供商都提供状态页面，详细说明正常运行时间、过去发生的事件和其他相关信息。例如，在撰写本文时， OpenAI 的 API 正常运行时间为 99.86%。查看解决问题所需的时间以及服务的整体正常运行时间，将让您了解公司对中断相关问题的响应程度。

DDoS 攻击对第三方 API 构成了重大威胁，而速率限制是防止这种攻击的好方法。在我们最近的速率限制成功指南中，我们讨论了这种方法对于减轻数据泄露影响的价值。您正在考虑的服务是否使用了它？

在理想情况下，API 提供商会对他们的正常运行时间和速率限制统计数据感到满意，并愿意与最终用户共享这些数据。如果他们犹豫不决，那么你应该问问自己为什么。

一般来说，发布 API 的新版本是一件好事。API版本控制意味着希望修复当前存在的问题或向响应添加新的端点/参数。然而，缺点是过度的版本控制可能会导致重大更改。这可能会让您作为 API 使用者难以实施修补程序，直到文档更新以反映您需要在应用程序中进行的必要更改。

有时，开发人员会继续托管与其 API 的弃用版本有关的文档，以及有关他们对服务所做的重大更改的补充信息。从整体上看，可以帮助分析公司更改其 API 的频率、他们过去是否遇到过重大问题等等。

正如 OWASP 的 API 安全十大概述中所述，不当的库存管理会对 API 造成重大风险，例如，当旧 API 版本或僵尸端点未修补地运行或使用较低的安全要求时。

对于影子 API而言，组织可能根本没有管理或保护 API。在决定使用 API 之前，尝试发现文档（和数据流）盲点始终是明智之举。OWASP 建议查找以下内容：

查看 API 的文档是否最新、全面且完全透明。

不幸的是，在别人的土地上建造建筑物总是存在一定的风险。正如我们上面所看到的，依赖没有得到妥善保护或在某种程度上不可靠的第三方 API 可能会导致灾难。或者，更有可能的是，它可能只会导致轻微的挫败感。

随着API 优先设计运动的兴起，更不用说使用 AI 和 LLM API 集成 genAI 功能的压力越来越大，我们预计 2024 年及以后 API 的消费范围将比现在更加广泛。

第三方 API 的性能（正常运行时间、版本控制、安全措施）一直都很重要。不过，许多组织现在对它们的依赖程度凸显了在使用它们之前确保其质量的重要性。如果您没有尽到应有的谨慎，那么审核现有集成还为时不晚。

作为 API 开发人员，您已经知道 API 的质量标志是什么样的。如果第三方 API 显示出让您不满意的缺陷，那么最好避免使用它。或者，回到之前的比喻，寻找另一条隧道……