您可能知道 Cloudflare 支持着近 20% 的 Web。但是，支持和保护网站及静态内容仅仅是我们工作的一小部分。实际上，我们网络上超过一半的动态流量不是来自网页，而是应用程序编程接口(API)流量。API 对网络运转至关重要。《2024 年 API 安全和管理报告》详细说明了我们如何保护客户，以及这对 API 安全的未来意味着什么，本博客文章是对报告的介绍和补充。与其他行业 API 报告不同，我们的报告不是基于用户调查，而是基于真实的流量数据。
如果您只关注我们今年报告中的一件事，那就是：很多组织未能掌握准确的 API 端点清单， 即使他们认为自己能够正确识别 API 流量。 Cloudflare 使用两种方法帮助组织发现他们所有面向公众的 API。首先，客户配置我们的 API 发现工具来监控他们已知 API 流量中存在的识别令牌。然后，我们使用一个机器学习模型来扫描这些已知的 API 调用，以及_所有_ HTTP 请求，识别可能未被计入的 API 流量。这两种方法之间的差异巨大：与自行报告的方法相比，我们通过基于机器学习方法发现的 API 端点多出 30.7% 。这表明近三分之一的 API 是 “影子 API” —— 并可能没有得到适当的清点和保护。
请继续阅读，以了解我们首份 API 安全报告中的更多内容和亮点。完整报告包含我们观察到并阻止的威胁的更新统计数据，以及我们对 2024 年的预测。我们预测，组织对 API 安全缺乏关注将导致复杂性和失控增加，而对生成式 AI 访问的增加将导致更多 API 风险。我们还预计 2024 年 API 业务逻辑攻击将增加。最后，上述所有风险都会导致围绕 API 安全的监管加码。
隐藏的攻击面
网页和 API 有什么不同？API 允许应用程序在后台快速轻松地检索数据或请求其他应用程序执行工作。例如，任何人无需成为气象学家就可以开发一个天气应用；开发人员可以编写页面或移动应用的结构，并使用用户的位置请求天气 API 以获取预报。关键是，大多数终端用户并不知道数据是由天气 API 提供的，而不是应用的所有者。
虽然 API 是互联网的关键基础设施， 它们也容易被滥用。Optus 在 API 身份验证和授权上的漏洞让一位威胁行为者将 1000 万个用户记录待价而沽， 政府机构已经就这些具体的 API 攻击发出了警告。组织中的开发人员经常会创建面向互联网的 API，供他们自己的应用程序使用以提高运行效率，但保护这些新的公共接口是安全团队的责任。如果记录 API 并使其引起安全团队注意的过程不明确，它们就会变成影子 API——在生产环境中运行但组织毫不知情。这就是安全挑战开始出现的地方。
为了帮助客户解决这个问题，我们发布了 API Discovery。在推出最新版本时，我们提到很少有组织拥有准确的 API 清单。安全团队有时被迫采取“发邮件询问”的方法来构建清单，这样做的结果是，一旦应用发布 API 有变化的新版本，清单就会过时。更好的方法是通过代码库变化来跟踪 API 的变化，以跟上新版本的发布。然而，这仍然有一个缺点，只能清点活跃维护的代码。尽管遗留应用程序仍在接收生产流量，但它们也许不会发布新版本。
Cloudflare 在 API 管理方面的方法包括使用基于机器学习的 API 发现和网络流量检查相结合的方式，创建一份全面准确的 API 清单。这对我们的 API Gateway 产品非常重要，以便客户管理他们面向互联网的端点并监控 API 的运行状况。API Gateway 还允许客户使用会话标识符（通常是标头或 cookie）来识别他们的 API 流量，这有助于在发现过程中识别特定 API 流量。
如前所述，我们的分析表明，即使是知识丰富的客户也经常忽略其 API 流量中的很大一部分。通过比较基于会话的 API 发现(使用 API 会话来精确定位流量)和基于机器学习的 API 发现(分析_所有_传入流量)，我们发现后者平均多发现 30.7% 的端点！如果没有广泛的流量分析，您可能会漏掉几乎三分之一的 API 清单。
即使不是 Cloudflare 客户，您也可以着手构建一个 API 清单。API 通常会以一种称为 OpenAPI 的标准化格式进行编目，很多开发工具可以创建符合 OpenAPI 格式的模式文件。如果您手头有这种格式的文件，您就可以通过搜集这些模式来自行构建一个 API 清单。这里有一个例子，展示了如果您有一个名为`my_schema.json` 的 OpenAPI v3 格式文件，如何从中提取端点：
除非您从应用程序开发过程最初就一直在生成 OpenAPI 模式并跟踪 API 清单，否则您的生产应用程序 API 清单中可能会遗漏一些端点。
import json
import csv
from io import StringIO
# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
schema = json.load(file)
# Prepare CSV output
output = StringIO()
writer = csv.writer(output)
# Write CSV header
writer.writerow(["Server", "Path", "Method"])
# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
url = server['url']
for path, methods in schema['paths'].items():
for method in methods.keys():
writer.writerow([url, path, method])
# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)精确的速率限制可以最大程度减少攻击的可能性
在防止滥用方面，大多数从业者的首先会想到速率限制。在您的 API 上实施限制非常有用，可以控制滥用行为并防止源服务器的意外过载。 但怎么知道您选择的速率限制方法是否正确呢？方法可能各不相同，但通常归结选择的错误代码，以及限制值本身的依据。
对于一些 API，从业者将配置速率限制错误以返回 HTTP 403（禁止）响应，而其他则会返回 HTTP 429（请求过多）。使用 HTTP 403 似乎没有问题，直到您意识到其他安全工具也在用 403 代码响应。当您遭受攻击时，要弄清楚哪些工具负责哪些错误/阻止可能会很困难。
如果使用 HTTP 429 来响应速率限制，攻击者会立刻知道他们已经受到速率限制，并能刚好保持在限制水平下而不被发现。如果您只是为了确保后端系统稳定而限制请求，这样做或许没问题，但它可能会向攻击者透露您的策略。此外，攻击者可以“扩展”到更多 API 客户端，从而成功进行超过速率限制的请求。
两种方法都各有利弊，但我们发现到目前为止，在所有 4xx 和 5xx 错误信息中，大多数 API 都以 HTTP 429 响应（接近 52%）。
除了使用响应码外，速率限制规则本身的情况如何呢？实施基于 IP 地址的请求限制可能很有诱惑力，但我们建议您将基于会话 ID 的限制作为最佳实践，并仅在没有会话 ID 时才回退到 IP 地址（或 IP+JA3 指纹）。基于用户会话而非 IP 设置速率限制，将能可靠地识别您的真实用户，并最大程度减少由于共享 IP 空间而导致的误报。Cloudflare 的 Advanced Rate Limiting 和 API Gateway 都提供容量滥用保护，通过分析每个 API 端点的会话流量来实施限制，并为设置每个端点的速率限制提供一键式解决方案。
为确定您的速率限制值，Cloudflare API Gateway 对您的会话请求统计数据进行计算。按照客户配置的 API 会话标识符，我们识别到您 API 的_所有_会话，观察每个会话的请求分布情况，建议一个限制值。然后，我们针对这个分布上的 p50、p90 和 p99 计算统计 p 值 （描述不同流量分组的请求率），并使用该分布的方差来产生 API 清单中每个端点的推荐阈值。推荐值可能与 p 值不一致，这是一个重要的区别，也是不单独使用 p 值的原因。除了推荐值，API Gateway 还会告知用户我们对推荐值的信心。通常情况下，我们能收集到的 API 会话越多，我们对推荐值的信心就越足。
激活速率限制非常简单，仅需点击“创建规则”链接，API Gateway 会自动将您的会话标识符带到“高级速率限制”规则创建页面，确保您的规则具有高度准确性，以防御攻击并最大程度减少误报（与过于宽泛的传统限制相比）。
API 也会受到 Web 应用攻击的侵害
API 也不能幸免于常见的 OWASP Top 10 攻击，例如 SQL 注入。API 请求的正文内容也可能像网页表单输入或 URL 参数一样成为数据库输入。重要的是，确保您的Web 应用程序防火墙(WAF)也保护您的 API 流量，以防这些类型的攻击。
实际上，当我们查看 Cloudflare 的 WAF 托管规则时，发现注入攻击是 Cloudflare 观察到的针对 API 的第二大常见威胁手段。最常见的威胁是 HTTP 异常。HTTP 异常的例子包括方法名格式错误、标头中的空字符、非标准端口，或者 POST 请求的内容长度为零。以下是我们观察到针对 API 的其他主要威胁的统计数据：
图中没有显示身份验证和授权失败。身份验证和授权失效是指 API 未能核实发出信息请求的实体是否确实有权限请求那些数据。另一种情况是，攻击者试图伪造凭据并将限制较少的权限插入到具有更多受限权限的现有（有效）凭据。OWASP 将这些攻击分为几种不同的类型，但主要类别是对象级授权失效(BOLA)和函数级授权失效(BFLA)攻击。
BOLA/BFLA 攻击得以成功的根本原因在于，源 API 没有对请求这些记录的身份检查数据库记录的正确所有权。追踪这些特定的攻击可能很困难，因为权限结构可能根本不存在、不充分或实施不当。您能看出这里先有鸡还是先有蛋的问题吗？如果我们知道正确的权限结构，阻止这些攻击将会很容易，但如果我们或我们的客户知道正确的权限结构或能保证其执行，那么这些攻击从一开始就不会成功。敬请期待我们未来的 API Gateway 功能发布，届时我们将利用对 API 流量常态的了解，自动建议安全策略，突出并阻止 BOLA/BFLA 攻击。
即使您没有可用的细粒度授权策略，仍有四种方法堵塞可能您的 API 中可能存在的身份验证漏洞：
首先，对每个公开可访问的 API 执行验证，除非是业务批准的例外情况。考虑类似 mTLS 和 JSON 网络令牌之类的技术。
限制向服务器发起 API 请求的速度，以减缓潜在攻击的速度。
阻止异常数量的敏感数据外流。
阻止攻击者跳过合法的 API 请求序列。
API 现在令人意外地更多是由人而不是机器驱动
如果您从智能手机出现之前、上网的人还较少的时候就开始接触技术，您可能会不禁认为 API 仅仅被用于机器与机器之间的通信，例如夜间的批处理作业。然而，事实完全不是那样。正如我们所讨论的，许多 Web 和移动应用都是由 API 驱动的，它们支持从身份验证到交易再到媒体文件服务的各种事务。随着人们使用这些应用，API 流量也在相应增加。
我们可以通过观察节假日期间的 API 流量模式来展示这一点。在节假日中，人们聚集在朋友和家人身边，花更多的时间进行面对面的社交活动，减少上网时间。我们在下面的全球 API 流量图表上标注了常见的节假日和促销活动。请注意，在黑色星期五和网络星期一期间，当人们在线购物时，流量会在+10%的水平左右达到高峰，但在圣诞节和元旦期间，流量出现下降。
这种模式与我们在常规 HTTP 流量中观察到的模式非常相似。显然，API 不再是专属于自动化过程的领域，而是与人类行为和社会趋势密切相关。
建议
全面的 API 安全并没有万能的解决方案。为了达到最佳效果，Cloudflare 推荐四种策略来改善 API 的安全态势：
通过统一的控制平面将 API 应用开发、可见性、性能和安全性结合起来，维护一个最新的 API 清单。
通过利用机器学习技术的安全工具，释放人力资源并减少成本。
采用正面安全模式来保护 API（参见下文有关正面和负面安全模式的解释）。
随着时间的推移，衡量并改善组织的 API 成熟度级别（参见下文关于 API 成熟度级别的解释）。
我们所说的“正面”或“负面”安全模式是什么意思？在负面模式中，安全工具寻找已知的攻击迹象并采取行动阻止这些攻击。在正面模式中，安全工具寻找已知的合法请求并只允许这些请求通过，阻止所有其他请求。API 通常采取结构化方式，采用正面安全模式以达到最高级别的安全性合情合理。您也可以结合使用不同的安全模式，比如以负面模式使用 WAF（Web 应用程序防火墙），并以正面模式使用 API 模式验证。
这里有一种快速评估组织 API 安全成熟度级别的方法：新手组织从编制他们的第一个 API 清单开始，无论多么不完整。更成熟的组织将努力实现 API 清单的准确性和自动更新。最成熟的组织会在他们的 API 上以正面安全模式中积极执行安全检查，实施 API 模式，有效身份验证，并检查滥用行为的迹象。
预测
最后，我们对 2024 年及以后有如下四大预测：
**失控程度和复杂性增加：**我们调查了 API 安全与管理领域的从业者，73%的受访者表示安全要求干扰了他们的生产力和创新。叠加日益庞杂的应用程序和不准确的清单，API 的风险和复杂性将会增加。
AI 使用更容易带来更多 API 风险： 生成式人工智能的兴起带来潜在风险，包括：人工智能模型的 API 容易受到攻击，以及开发人员发布带有缺陷、由 AI 编写的代码。Forrester 预测，在 2024 年，如果没有适当的安全措施，“至少会有三起数据泄露事件将被公开归咎于不安全的 AI 生成代码——要么因为生成的代码本身存在安全缺陷，要么因为 AI 建议的依赖关系存在漏洞。”
**基于业务逻辑的欺诈攻击增加：**职业诈骗者像经营企业一样运作他们的诈骗活动，他们也有像其他任何业务一样的成本。我们预计攻击者将比过去几年更高效地针对 API 运行欺诈机器人。
监管加码： PCI DSS 直接针对 API 安全的第一个版本将于 2024 年 3 月生效。请与您的审计部门查看您所在行业的具体要求，以便在新要求生效时做好准备。
如果您对完整报告感兴趣，可在这里下载《2024 年 API 安全报告》，其中包含有关我们建议的全部细节。
Cloudflare API Gateway 是我们的 API 安全解决方案，面向所有 Enterprise 客户提供。如果您没有订阅 API Gateway，请点击这里在 Cloudflare 仪表板中查看您的首次 API Discovery 结果并开始试用。要了解如何使用 API Gateway 保护您的流量，请点击这里查看我们的开发文档， 点击这里查看我们的入门指南。