一直以来，安全是一场攻防博弈。需要筑起高墙、设置关卡和编写规则，以阻止看似可疑的流量。多年来，Cloudflare 一直是这个领域的领军企业：我们的应用安全平台旨在发现攻击，在恶意请求到达源站之前就将其拦截。但对于 API 安全而言，仅仅依靠防御是不够的。
这就是我们今天推出 Cloudflare Web and API Vulnerability Scanner 测试版的原因。
首先，我们来看看 OWASP API Top 10 中最普遍、最难发现的威胁：失效的对象级授权 (BOLA)。我们将逐步添加更多漏洞扫描类型，包括 API 和 Web 应用威胁。
当今最危险的 API 漏洞，并不是 WAF 可以轻松识别的通用注入攻击或格式错误的请求。它们都是逻辑缺陷：完全符合协议和应用规范的有效 HTTP 请求，但却违背了业务逻辑。
要发现这些漏洞，就不能只是被动地等待攻击发生。必须积极主动地寻找它们。
我们将首先向 API Shield 客户提供 Web and API Vulnerability Scanner。请继续阅读，了解我们为什么关注首个版本的 API 安全扫描功能。
在 Web 应用程序领域，漏洞通常看起来像是语法错误。SQL 注入攻击尝试看起来像是将代码插入到应该放置数据的位置。跨站脚本 (XSS) 攻击看起来像是表单字段中的脚本标记。这些漏洞都有具体特征。
API 漏洞则不同。举例来说，假设有一个外卖移动应用，它仅与后端 API 通信。我们以订单端点为例：
端点定义：/api/v1/orders
方法 | 资源路径 | 描述 |
GET | /api/v1/orders/{order_id} | 检查状态。返回特定订单的跟踪状态（例如，“厨房正在备餐”）。 |
PATCH | /api/v1/orders/{order_id} | 更新订单。允许用户修改取货地点或添加配送说明。 |
在类似 BOLA 的授权失效攻击中，用户 A（攻击者）请求更新属于用户 B（受害者）的已付款订单的送货地址。攻击者只需在 PATCH 请求中插入用户 B 的 {order_id} 即可。
以下是该请求的示例，其中“8821”是用户 B 的订单 ID。请注意，用户 A 已使用其有效令牌进行了完全身份验证：
PATCH /api/v1/orders/8821 HTTP/1.1
Host: api.example.com
Authorization: Bearer <User_A_Valid_Token>
Content-Type: application/json
{
"delivery_address": "123 Attacker Way, Apt 4",
"instructions": "Leave at front door, ring bell"
}
请求头有效。身份验证令牌有效。模式正确。对于标准的 WAF 来说，这个请求看起来完美无缺。如果由真人手动发送攻击请求，即使是 Bot Management 也可能被欺骗。
用户 A 现在将收到用户 B 的外卖！漏洞存在的原因在于 API 端点未能验证用户 A 是否拥有查看或更新用户 B 数据的权限。这是逻辑错误，而不是语法错误。要解决这个问题，API 开发人员可以实施一个简单的检查：if (order.userID != user.ID) throw Unauthorized;
可以通过主动发送 API 测试流量或被动监听现有 API 流量来检测此类漏洞。通过被动扫描发现这些漏洞，需要一定的上下文。去年，我们推出了适用于 API Shield 的 BOLA 漏洞检测。此项检测功能通过被动扫描客户流量中的使用异常情况，自动发现这些漏洞。若要成功进行这种扫描，则需要了解什么是“有效”的 API 调用，可变参数是什么，典型用户的行为模式，以及这些参数受到操纵时的 API 行为。
然而，即使能够使用 API Shield 的 BOLA 漏洞检测功能，安全团队也可能因某些原因无法获得这些上下文。开发环境可能需要测试，但缺乏用户流量。生产环境可能（幸运的是）没有攻击流量，但仍然需要进行分析，等等。在这些情况下，为了更主动地进行安全防护，团队可以采用动态应用程序安全测试 (DAST)。通过创建专门用于安全测试的全新流量配置文件，DAST 工具可以随时在任何环境中查找漏洞。
遗憾的是，传统 DAST 工具的准入门槛很高。它们通常难以配置；需要手动上传和维护 Swagger/OpenAPI 文件；与现代复杂的登录流相比，难以正确地进行身份验证；以及可能根本没有特定于 API 的安全测试（例如 BOLA)。
在上面的外卖订单示例中，我们假设攻击者可以找到有效的订单进行修改。虽然攻击者通常可以通过各种途径在生产环境中实时收集此类情报，但在安全测试实践中，必须先创建自己的对象，然后才能测试 API 的授权控制。对于典型的 DAST 扫描来说，这可能是一个问题，因为许多扫描器会单独处理每个请求。这种方法无法将不同请求按照必要的逻辑模式链接在一起，从而无法发现失效的授权漏洞。传统 DAST 扫描器也可能孤立存在于安全工具和编排环境中，导致其扫描结果无法共享或在上下文中查看。
Cloudflare 的漏洞扫描之所以不同，主要有几个原因。
首先，Security Insights 会并列显示新扫描的结果与现有的 Cloudflare 安全性发现，以便提供更多上下文信息。可以在一个地方集中查看所有安全态势管理信息。
其次，我们已经了解您的 API 的输入和输出。如果您是 API Shield 客户，就意味着 Cloudflare 已经了解您的 API。我们的 API 发现和模式学习功能会被动地记录您的端点并学习其流量模式。虽然您需要手动上传 OpenAPI 规范才能开始使用我们的初始版本，但在未来的版本中，您无需上传 OpenAPI 规范即可快速开始。
第三，因为我们位于网络边缘，所以我们可以将被动流量检测信息转化为主动情报。通过向漏洞扫描器发送新的 HTTP 请求，可以轻松验证 BOLA 漏洞检测风险（通过流量检查发现）。
最后，我们构建了一个全新的、有状态的 DAST 平台，下文将详细介绍。大多数扫描器需要花费数小时进行设置，才能“教会”工具如何与 API 通信。利用 Cloudflare 平台，您可以有效跳过这个步骤，快速开始。您提供 API 凭证，我们使用您的 API 架构自动制定扫描计划。
API 通常使用 OpenAPI 模式进行记录。这些模式定义了主机、方法和路径（通常称为“端点”），以及传入请求和响应的预期参数。为了自动制定扫描计划，我们必须首先理解适用于待扫描 API 的相关规范。
Cloudflare 扫描器的工作方式是从 OpenAPI 文档构建 API 调用图，然后使用攻击者和所有者上下文遍历该 API 调用图。所有者创建资源，攻击者随后尝试访问这些资源。攻击者使用自己的一组有效凭证进行完全身份验证。如果攻击者成功读取、修改或删除非所有者资源，则表明存在授权漏洞。
例如，结合上述 ID 为 8821 的外卖订单。为了使服务器端资源存在，它需要最初由所有者创建，很可能是通过一个没有或只有极少依赖项（之前必要的调用和结果数据）的初始 POST 请求来实现。将 API 建模为调用图，这样的端点就构成了一个节点，其传入边缘（依赖项）很少或没有。任何后续请求，例如上述攻击者的 PATCH 请求，依赖于初始请求 (POST) 的数据（数据为 order_id）。如果缺少任何数据，PATCH 请求将无法继续执行。
图中紫色箭头所示是 API 图中的节点，通过 POST /api/v1/orders/{order_id}/note/{note_id} 端点向订单添加备注时需要访问这些节点。重要的是，图中所示的任何步骤或逻辑在 OpenAPI 规范中都未提供！必须通过其他方式进行逻辑推理，这正是 Cloudflare 漏洞扫描器将自动执行的操作。
为了可靠地自动规划对各种 API 扫描，我们必须从头开始准确地建模这些端点关系。但这会带来两个问题：API 规范的数据质量得不到保证，即使功能完整的模式也可能存在命名歧义。考虑上述 API 的简化版 OpenAPI 规范，它可能如下所示
openapi: 3.0.0
info:
title: Order API
version: 1.0.0
paths:
/api/v1/orders:
post:
summary: Create an order
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
product:
type: string
count:
type: integer
required:
- product
- count
responses:
'201':
description: Item created successfully
content:
application/json:
schema:
type: object
properties:
result:
type: object
properties:
id:
type: integer
created_at:
type: integer
errors:
type: array
items:
type: string
/api/v1/orders/{order_id}:
patch:
summary: Modify an order by ID
parameters:
- name: order_id
in: path
我们可以看到 POST 端点返回以下响应：
{
"result": {
"id": 8821,
"created_at": 1741476777
},
"errors": []
}
对于真人观察者而言，很快就能看出 $.result.id 就是 PATCH 端点要注入到 order_id 的值。id 属性也可能被称为 orderId、value 或其他名称，并且可以任意嵌套。OpenAPI 文档中这些细微的不一致之处，对于启发式推理方法来说难以处理。
Cloudflare 扫描器使用我们自有的 Workers AI 平台来解决这种模糊的问题空间。诸如 OpenAI 的开放权重模型 gpt-oss-120b 之类的模型功能强大，可以可靠地匹配数据依赖关系，并在必要时生成逼真的虚假数据，从而有效地填补 OpenAPI 规范中的空白。该模型利用结构化输出，生成 API 调用图表示（供 Cloudflare 扫描器遍历），并相应地注入攻击者与所有者的凭证。
这种方法利用人工智能，解决了需要人类智能来推断 OpenAPI 架构中的授权与数据关系。结构化输出在 gpt-oss 自然语言世界与机器可执行指令之间架起桥梁。除了 Workers AI 解决规划问题之外，在 Workers AI 上进行自托管意味着我们的系统可以自动受益于 Cloudflare 高可用的全球分布式架构。
构建让客户信任且愿意使用其 API 凭证的漏洞扫描器，需要成熟、可靠的基础设施。我们没有浪费时间做无用功。相反，我们集成了经过验证且已在 Cloudflare 内部部署的服务，用于扫描器平台的两个关键组件：扫描器的控制平面，以及扫描器的密钥存储。
扫描器的控制平面与 Temporal 集成，用于编排扫描，Cloudflare 的其他内部服务已依赖于此。Temporal 的持久执行框架可以有效管理每次扫描中执行的、复杂的众多测试计划。
整个后端均使用 Rust 编写，Rust 是 Cloudflare 基础设施服务中广泛采用的语言。这让我们能够重用内部库并在团队之间共享架构模式。这也使扫描器有可能在未来与其他 Cloudflare 系统（例如 FL2 或测试框架 Flamingo）集成，从而更紧密地协调扫描与处理边缘请求或测试基础设施等任务。
通过 HashiCorp 的 Vault Transit Secret Engine 实现凭证安全
扫描失效的身份验证和授权漏洞，需要处理 API 用户凭证。Cloudflare 非常重视这份责任。
我们使用 HashiCorp 的 Vault Transit Secret Engine (TSE) 提供加密即服务，确保我们的公共 API 层对未加密的客户凭证的访问权限极低。凭证提交后，立即由 TSE 进行加密（TSE 负责加密但不存储密文），随后将其存储在 Cloudflare 基础设施上。
Cloudflare API 无权解密此数据。相反，解密仅在最后阶段进行，即：测试计划向客户的基础设施发出请求时。只有执行测试的 Worker 才有权请求解密，我们使用 Rust 内部的严格类型化机制和额外的安全保障措施来强化这一限制，从而强制对解密方法实施最小化访问。
我们还通过定期轮换和使用 TSE 进行重新封装，进一步保护客户凭证，从而降低风险。这个过程意味着我们只能与新的密文交互，且原始密钥始终无法查看。
我们从今天开始推出面向所有 API Shield 客户的 BOLA 漏洞扫描公测版，并且正在开发的未来版本将会增加 API 威胁扫描功能。通过 Cloudflare API，以编程方式触发扫描、管理配置和检索结果，从而将其直接集成到 CI/CD 管道或安全仪表板。对于 API Shield 客户：请查看开发人员文档，立即开始扫描端点，发现是否存在 BOLA 漏洞。
我们首先关注 BOLA 漏洞，因为此类漏洞是最难解决的 API 漏洞，也是客户面临的最高风险。不过，这款扫描引擎的设计初衷是可扩展的。
在不久的将来，我们计划扩展扫描器的功能，使其能够检测 OWASP Web Top 10 中最常见的漏洞：例如 SQL 注入 (SQLi) 和跨站脚本攻击 (XSS) 等典型 Web 漏洞。如需及时接收发布通知，请在此处注册加入候补名单，您将第一时间了解 Cloudflare 何时将引擎检测范围扩展到常见 Web 应用漏洞。