为什么 API 安全测试会漏掉跨资产攻击链
仅测试 API 的扫描器会漏掉始于移动应用、Web 包或代码中密钥或路由的攻击链。本文介绍两条真实攻击链和一份 8 步测试清单。
您的 API 扫描器可能交出一份干净的报告，而攻击者却长驱直入。攻击者的请求是有效的，携带的是真实令牌，服务器也正确地作出了响应。问题在于令牌从何而来。它来自扫描器从未检查过的地方：编译进移动应用中的一个字符串、遗留在 JavaScript 包中的一条路由，或仍留在 Git 历史中的一个密钥。
单靠 API 安全测试之所以不够，是因为许多高影响的 API 入侵并非始于 API。它们始于从移动应用、JavaScript 包或源代码中提取的凭据、路由或请求格式，随后这些内容被作为有效请求重放。只测试 API 的扫描器永远看不到攻击链的起点。
在我们评估过的一款 iOS 应用中，一个硬编码的 Auth0 密钥导致了一个包含 1,000 条记录的用户目录泄露，尽管针对该凭据的第一个发现已被标记为“已修复并验证”（Fixed & Verified）。这个案例详见下文。本指南面向 API 为移动端或 Web 客户端提供服务的 AppSec 负责人和 DevSecOps 工程师。
执行摘要（TL;DR）
- 在我们的评估中，许多最严重的 API 发现并非始于 API。它们始于从客户端应用或代码中提取的凭据或路由，随后被作为有效请求重放。
- 每次只测试一种资产的扫描器，各自只能看到这条链的一半。事后将它们的报告汇集到一个控制台中，并不能把两半连接起来。
- 要发现这类攻击链，需要在同一次评估中测试客户端应用、代码和线上 API，并在服务器端进行修复。
什么是跨资产攻击链？ 跨资产攻击链是分布在多个资产上的一系列弱点，这些资产包括移动应用、Web 前端、源代码仓库和后端 API 等。每个弱点单独看都不起眼。但组合起来，就能让攻击者访问本不应触及的数据或功能。
典型的攻击链包含 3 个步骤：
- 提取客户端或代码中的某样东西：令牌、签名密钥、未公开的路由或请求格式。
- 重放它，作为有效请求发送给后端 API。
- 提权，利用服务器上的授权缺口：访问其他用户的对象（BOLA）、特权功能（BFLA）或更宽的令牌权限范围。
这里没有任何一步看起来像攻击。第一步只是一个静态字符串，第二步是一个经过身份验证的请求，第三步是一个普通的 API 响应。只有按顺序把它们串起来看，入侵才会显现。
跨资产攻击链在实践中是什么样的？
下面两条攻击链来自 Ostorlab 的真实评估，本博客均有更详细的介绍。两者都用到了 Ostorlab Agentic Deep Scan，它会针对某个资产运行自主测试智能体：第一个案例中是移动二进制文件，第二个案例中是源代码。只有当提取出的凭据或路由在线上后端被重放后，它们才成为确认的入侵。
1. 从 iOS 应用中硬编码的 Auth0 客户端密钥到租户级管理员权限范围
在《AI 如何发现复杂漏洞》一文介绍的一次评估中，一款 iOS 应用内置了 Auth0 机器对机器（M2M）的 client_id 和 client_secret。两者都是在构建时通过 Flutter 的 DART_DEFINES 嵌入的。该应用用它们来调用一个内部服务。
针对该凭据的第一个发现仅限于应用所调用的那一个受众（audience），被评为高危，并已标记为“已修复并验证”。这次修复关闭的是应用所使用的路径，而不是该凭据能触及的所有内容。
静态扫描器会报告这个字符串。就应用合法请求的受众而言，API 扫描器看到的是一个权限范围正确的令牌。但智能体提出了一个不同的问题：M2M 客户端可以被授权访问多个 API，那么这个客户端还被授权调用什么？
它针对该租户的 /oauth/token 端点尝试了 38 个候选受众。Auth0 Management API（https://<tenant>.auth0.com/api/v2/）返回了 HTTP 200，以及一个持有 8 个管理权限范围的令牌，其中包括 update:users、delete:users 和 create:client_credentials。随后，一个只读的 GET 请求就暴露了该租户包含 1,000 条记录的完整用户目录，其中包括个人身份信息（PII）。整个过程没有执行任何写操作，但该令牌本可以创建、更新和删除用户。第二个发现被评为严重，并且仍处于未关闭状态。
为什么单层测试会漏掉它：凭据位于二进制文件中，而权限过宽的授权位于身份提供商的配置中。两者都不会出现在 API 规范中。
2. 转移了所有权的创建端点（BOLA）
在 GoPhish 源代码评估中，人工审查与 Ostorlab Agentic Deep Scan 结合使用，发现群组创建端点（POST /api/groups/）会执行静默的 upsert 操作。一个携带其他用户群组 id 的有效 JSON 请求体，会覆盖该群组的收件人数据，并将其所有权转移给攻击者。
Agentic Deep Scan 在代码中发现了这一模式：创建处理程序接受 id。随后，评估以第二个用户的身份，在一个使用合成账户、相互隔离的本地 GoPhish 实例上重放该请求，从而确认了这一问题。这种重放会覆盖数据，因此应该在实验环境中进行，而不是在生产环境中。
为什么单层测试可能漏掉它：该请求格式正确且经过身份验证，缺陷位于所有权逻辑而非输入验证中，因此契约检查和基于模式（schema）的模糊测试都没有可标记的内容。多用户测试只有在创建请求中发送了其他用户的 ID 时才能发现它。而阅读处理程序代码恰好能指明应该在哪里尝试。
为什么单层 API 扫描器会漏掉这些攻击链？
单层扫描器之所以漏掉这些攻击链，是因为每个扫描器只能看到自己的资产，因此没有一个能把在客户端中发现的密钥与该密钥所能解锁的 API 联系起来。大多数安全工具只覆盖技术栈的一个角落：源代码、网关或 WAF 流量，或者针对预发布服务器的测试请求。它们都没有问题；只是各自孤立地测试自己的资产。
但调用后端 API 的有移动二进制文件（iOS .ipa、Android .apk）、单页 Web 应用、合作伙伴集成和内部服务，而它们都会把配置——往往还有密钥——发布到攻击者可以读取的地方。逐个测试时，每个资产都可能通过，而它们之间的攻击链却无人察觉。现在已有一些平台将代码、运行时和 API 测试结合起来，而这正是发现这些攻击链所需要的。
API 凭据和路由从哪里泄露？
API 凭据和路由通常从攻击者可以获取的 5 个来源泄露：移动二进制文件、Web 包、源代码仓库与 CI、API 文档，以及 WebSocket 等辅助通道。以下是我们在评估中最常遇到的几种：
| 来源 | 攻击者提取的内容 | 对 API 的典型影响 |
|---|---|---|
| 移动二进制文件（APK / IPA / AAB） | 绝不应随应用发布的机密凭据，例如 M2M 客户端密钥和共享的 client_secret 值（原生应用的公开 client_id 本就会被看到）、在构建时注入的特权 API 密钥（例如 Flutter DART_DEFINES 或 Android BuildConfig）、加密密钥和请求签名逻辑、隐藏或调试端点 |
铸造令牌、绕过请求签名、调用内部或预发布 API |
| Web 包（SPA JavaScript、source map） | UI 从不显示的管理和内部路由、受功能开关控制的端点、第三方 API 密钥、GraphQL 操作名称 | 未公开的端点（影子 API）、无需 UI 检查即可访问的特权功能（BFLA） |
| 源代码仓库与 CI | 提交历史中的密钥、部署令牌、路由定义、缺少授权中间件的处理程序 | 直接的已认证访问，以及一份缺少所有权检查的路由的精确清单 |
| API 文档与集合（OpenAPI、Postman、GraphQL 内省） | 完整的请求结构、仍在线上运行的已弃用版本、对象标识符格式 | 大规模枚举，以及通过旧 API 版本进行访问（资产清单管理不当） |
| 辅助通道（WebSocket、gRPC-web） | 通道暴露的端点路径和操作名称，以及跳过 HTTP 身份验证中间件的握手 | 未经身份验证的数据流或订阅（身份验证失效、BFLA） |
仅依据 OpenAPI 文件和一个测试账户工作的扫描器，一开始就没有这些素材。因此，它测试的是行为规范的客户端所使用的 API，而不是攻击者将会使用的那个 API。
哪些 OWASP API Top 10 风险借助 API 之外的上下文更容易发现？
OWASP API Security Top 10（2023）中的风险都是服务器端缺陷：BOLA 和 BFLA 始终要在 API 中修复。但其中有几项借助 API 之外的上下文（例如客户端应用或源代码）更容易发现或验证：
| OWASP API 风险 | 有助于发现或验证它的外部上下文 | 仅测试 API 的扫描能看到什么 |
|---|---|---|
| API1: Broken Object Level Authorization（对象级授权失效，BOLA） | 从客户端应用中了解到的对象标识符格式和请求加密方式 | 对其自身测试对象的请求，这些请求如预期般成功 |
| API2: Broken Authentication（身份验证失效） | 从二进制文件或代码仓库中提取的客户端凭据或长期有效的令牌 | 什么也看不到，除非有人把泄露的凭据交给它 |
| API3: Broken Object Property Level Authorization（对象属性级授权失效） | 在客户端模型或 GraphQL 类型中发现的隐藏字段 | 仅限规范中记录的字段 |
| API5: Broken Function Level Authorization（功能级授权失效，BFLA） | Web 包中的管理路由，以及 WebSocket 等辅助通道 | 规范中列出的 HTTP 路由，并且仅限其测试账户被授予的角色 |
| API8: Security Misconfiguration（安全配置错误） | 与已发布凭据关联的权限过宽的 OAuth 客户端、受众或云角色 | 它已知端点上的传输层和请求头问题 |
| API9: Improper Inventory Management（资产清单管理不当） | 客户端和代码中引用的预发布主机、旧版本和调试端点 | 仅限提供给它的资产清单 |
其余 4 项（API4 Unrestricted Resource Consumption、API6 Unrestricted Access to Sensitive Business Flows、API7 SSRF 和 API10 Unsafe Consumption of APIs）通常从 API 侧进行测试。
为什么 API 网关、ASPM 平台或扫描器流水线发现不了这些攻击链？
大多数团队已经拥有 API 网关、ASPM 平台，或运行多个扫描器的 CI 流水线。它们各有帮助，但没有一个能单独地用泄露的凭据去测试 API。以一条常见的攻击链为例：一款移动应用内置了一个硬编码的 API 令牌，攻击者用它调用后端，而一处错误配置赋予了该令牌管理权限。
API 网关放行了请求
网关会检查请求格式是否正确、实施速率限制，并验证令牌是否真实且签名正确。在这次攻击中，请求是有效的，令牌也是真实的。网关无从得知，一个随公开应用发布的令牌本不应拥有管理权限。
ASPM 聚合无法串联线索
应用安全态势管理（ASPM）平台会将来自移动、代码和 API 扫描器的发现汇集到一个视图中。这有助于分级处理和明确责任归属。但如果关联发生在扫描结束之后，就不会有任何跨资产的测试。有些平台捆绑了自己的扫描器，因此关键的区别在于关联何时发生，而不是产品类别：
| 维度 | ASPM 聚合 | 扫描内关联 |
|---|---|---|
| 关联何时发生 | 在每个扫描器完成之后 | 在扫描过程中，测试仍在运行时 |
| 关联的对象 | 已经存在的发现 | 原始发现：令牌、路由、请求格式 |
| 能否用泄露的令牌测试 API？ | 仅靠聚合不行；它只是把两个发现关联起来 | 能，令牌会成为下一次线上测试的输入 |
| 输出 | 两个相关的发现，严重程度往往不同 | 一条经过验证的攻击链，附带请求和响应证据 |
| 严重程度 | 沿用各扫描器的评级 | 基于攻击链被证明的影响 |
扫描器流水线是依次运行工具，而不是协同运行
在 CI 中串联扫描器会让它们一个接一个地运行，但没有一个能看到其他扫描器发现了什么。移动扫描器在 APK 或 IPA 中发现了一个客户端密钥，却无法判断它在哪里有效，于是提交一个低危的静态发现。API 扫描器依据公开的模式测试后端，从来不知道这个密钥的存在。
多资产扫描如何测试整条攻击链？
扫描内关联是指在一个资产中的发现（例如源代码中的一条路由或客户端二进制文件中的一个令牌）会立即成为针对线上后端测试的输入。Ostorlab 的 Multi-Asset Deep Agentic Scan 正是基于这一理念构建的。Agentic Deep Scan 每次调查一个资产，而 Multi-Asset Deep Agentic Scan 则在一次扫描中，对相关资产（包括移动应用、后端 API、Web 前端和源代码）运行一次统一的智能体式调查。
在扫描内部，移动二进制文件、Web 前端、后端 API 和源代码都会汇入同一个线上验证步骤，在这里，泄露的令牌或路由会被拿到后端进行测试。扫描分为 3 个阶段：
- 发现。智能体反编译移动二进制文件（APK、AAB 和 IPA），读取 Web JavaScript 包、source map、代码仓库和文档，并在经过插桩的 Android 和 iOS 设备上运行应用，同时捕获其流量。它还会探测常见的 OpenAPI 和 Swagger 路径，并运行 GraphQL 内省。OpenAPI（Swagger 2.0 或 OpenAPI 3.x）或 GraphQL 模式能从一开始就提升覆盖范围，但并非必需。
- 关联。端点、基础 URL、OAuth 受众、请求参数和嵌入的令牌等客户端素材会与后端的路由和服务进行匹配。在代码或字节码中发现的密钥会被视为有待调查的线索，而不是已确认的漏洞。
- 验证。每条可能成立的攻击路径都会交给一个漏洞利用智能体，由它针对线上后端进行测试，例如检查某个令牌能否通过身份验证，或某个端点是否返回了不应返回的数据。经过验证的发现会包含确切的请求和响应，方便您的团队复现。
许多密钥扫描器会报告形似凭据的字符串，即便是那些会检查密钥是否有效的扫描器，也不会测试它能通过您的 API 触及什么。而在这里，只有在攻击链被复现之后，才会报告这条链及其带来的更高严重程度。独立的发现仍会根据其自身情况进行报告：一个目前无法使用的泄露凭据仍然值得修复。
当前的协议覆盖情况：
- GraphQL：通过 HTTP 上的内省或上传的模式进行映射，然后使用生成的查询和变更进行测试。
- SOAP：进行线上测试。
- gRPC：依据
.proto定义分析授权和数据暴露风险。目前尚不支持实时 gRPC 调用和服务器反射。 - WebSocket 和 GraphQL 订阅：Multi-Asset Deep Agentic Scan 目前尚不能通过 WebSocket 传输进行线上测试。
下文清单第 6 步中提到的 WebSocket 授权缺陷，是 Ostorlab 的 AI Pentest Engine 在另一次有针对性的评估中发现的；在多资产扫描中，WebSocket 授权仍需人工检查。
针对您的后端运行自主 API 测试安全吗？
安全，前提是有防护措施并使用预发布环境作为目标。测试线上 API 的智能体必须在不造成破坏的前提下证明影响，因此 Ostorlab 采用了多层控制：
- 智能体指令。智能体以最小的安全操作来证明影响：BOLA 或 BFLA 缺陷通过一次未授权的读取来展示，而不是修改记录；令牌则通过只读请求进行检查。智能体不会运行破坏性命令、打开反弹 shell、建立持久化、修改数据或吊销凭据。
- AI 模型之外的监督程序。一个独立的监督程序会在每次工具调用和请求目标执行之前，对照扫描范围进行检查，拦截超出范围的请求；如果某个智能体持续试图越出范围，就会终止扫描。我们的关于 AI 智能体范围偏移的事后复盘解释了这一层为何重要。
- 智能体之外的控制。防火墙规则限制了扫描智能体可以访问的范围，扫描器主机还对请求量设置了上限。
我们仍然建议使用专用测试账户，针对预发布或准生产环境运行多资产扫描。对于内部 API，本地部署的扫描器以容器形式在您的基础设施内运行，只建立出站连接来接收任务并返回发现。对于位于 WAF 或 IP 白名单之后的预发布 API，请将 Ostorlab 文档中公布的扫描器 IP 地址加入白名单。客户端证书目前还不是扫描设置项，因此对于启用双向 TLS 的 API，请在 mTLS 终止点之后运行本地部署的扫描器，这样扫描器就无需客户端证书。
如何测试您自己的技术栈是否存在跨资产攻击链？
您可以从开源工具和几个小时的专注工作开始。按照以下 8 个步骤，找出从移动端到 API、从代码到 API 以及跨传输协议的攻击链：
- 列出 API 的所有客户端。包括调用它的每一个移动应用、Web 前端、合作伙伴集成和内部服务，以及它们各自持有的凭据。
- 提取客户端所发布的内容。反编译最新的 Android 构建版本（
jadx -d out app.apk或apktool d app.apk）。对于 iOS，在已解密的 IPA 上运行unzip app.ipa -d out；App Store 的构建版本经过 FairPlay 加密，因此在解密之前无法搜索二进制文件中的字符串。将生产环境的 JavaScript 包和所有 source map 下载到同一文件夹中。然后搜索密钥和令牌（grep -rEai "api[_-]?key|secret|token|bearer" out/，其中-a让 grep 输出编译后二进制文件中的匹配项）以及主机名（grep -rEaoh "https?://[a-zA-Z0-9./_-]+" out/ | sort -u）。对于单个二进制文件，也可以使用strings -a <binary> | grep -Ei "secret|token"。 - 在授权范围内测试您找到的每个凭据。对于每个 OAuth 客户端，为您获授权测试的其他资源服务器和权限范围请求令牌（Auth0 将此参数称为
audience；RFC 8707 将其称为resource）。不要超出项目允许的范围进行盲目枚举。对于每个 API 密钥，检查范围内有哪些主机和环境接受它。我们关于发现和验证硬编码密钥的指南介绍了如何检查泄露的密钥能做什么。 - 将发现的路由与规范进行比较。出现在客户端或代码中、但不在 OpenAPI 或 GraphQL 模式中的路由，是潜在的影子 API。它可能是有意不公开的、动态的或不在范围内的，因此在将其视为影子 API 之前，请先确认它是线上的、面向 API 的、未受管理的，并且已获授权进行测试。
- 用“角色 × 租户”账户矩阵测试授权。两个普通用户是不够的。对每一项操作，测试跨租户的同角色访问和同一租户内的跨角色访问，包括接受
id的创建端点。 - 测试每一种传输方式，而不仅仅是 HTTP。每一种都需要单独检查。对于 WebSocket，在建立连接时和每一项操作上测试授权。对于 gRPC，测试方法级授权和元数据处理。对于 webhook，验证签名、时间戳、重放保护和租户路由。在由 Ostorlab 的 AI Pentest Engine 完成的一次 GraphQL 评估中，API 在 HTTP 上强制执行了角色控制，却接受了未经身份验证的 WebSocket 订阅。
- 检查旧版本和旧主机。在当前版本为
/v2/的地方调用/v1/，并尝试客户端中引用的预发布主机。这里介绍了API 版本不一致如何导致账户接管。 - 在每一个版本发布时重复。新的移动构建版本可能会带上上一次评估从未见过的密钥。
想要自动执行这份清单？Multi-Asset Deep Agentic Scan 可在一次扫描中自动完成提取、凭据、路由和授权这几个步骤：它会提取您的移动应用所发布的内容，针对线上 API 测试凭据和路由，并报告它所复现的攻击链。第 6 步中的 WebSocket 检查目前仍需人工完成。
如何防范跨资产攻击链？
这些修复属于架构层面。它们位于服务器端，或体现在客户端的构建方式中：
- 不要将特权密钥放在客户端中。将随移动应用或 Web 包发布的任何内容都视为公开内容。原生应用应使用带 PKCE 的授权码流程（Authorization Code flow）让用户登录，这样它们只持有短期有效、按用户签发的令牌。浏览器应用可以使用 backend-for-frontend（BFF）将令牌保留在客户端之外。我们关于硬编码密钥的指南介绍了常见模式。
- 严格限定机器凭据的权限范围。只授予每个 M2M 客户端访问一个 API 的权限，并只赋予其所需的最小权限范围集合；对于针对其他受众的令牌请求发出告警。
- 重新测试凭据本身，而不仅仅是路径。修复泄露的凭据时，要检查它仍能触及的每一个受众和权限范围，而不仅仅是应用使用的那一个。
- 在服务器上对每一项操作强制执行所有权检查。根据已认证的用户解析对象，绝不仅凭请求体中的
id来解析。在创建时，拒绝服务器端已存在对象的标识符（或强制执行仅插入语义），并检查所有权。对新对象使用客户端生成的 UUID 可以接受。 - 在各种传输方式之间使用同一套授权策略。WebSocket 和 gRPC 并不总能复用 HTTP 中间件，因此应集中定义策略，并在每个边界上强制执行：连接、每个操作或解析器、每条消息或事件，以及 gRPC 拦截器。
- 将资产清单视为一项安全控制。下线旧版本和预发布主机，并让规范与客户端实际调用的内容保持同步。
常见问题（FAQ）
API 安全中的跨资产攻击链是什么？
跨资产攻击链组合了多个资产中的弱点，这些资产包括移动应用、Web 前端、源代码和后端 API 等。典型的攻击链会从客户端提取凭据或路由，将其作为有效的 API 请求重放，并通过 BOLA 或 BFLA 等授权缺口进行提权。
为什么 API 扫描器检测不到硬编码在移动应用中的密钥？
API 扫描器使用提供给它们的凭据和规范来测试正在运行的后端。它们不会反编译移动二进制文件，因此永远看不到编译进应用中的密钥，也没有理由用这些密钥去测试 API。
ASPM 与多资产扫描有什么区别？
ASPM 平台会在每次扫描完成后，将来自不同扫描器的发现汇集到一个控制台中。多资产扫描执行的是扫描内关联：一个资产中的发现（例如移动二进制文件中的令牌）会在同一次扫描中被用来对后端 API 进行线上测试，并且只报告已复现的攻击链。
哪些 OWASP API Top 10 风险借助客户端或代码上下文更容易发现？
所有 OWASP API Top 10 风险都要在服务器上修复，但 Broken Object Level Authorization（API1）、Broken Authentication（API2）、Broken Object Property Level Authorization（API3）、Broken Function Level Authorization（API5）、Security Misconfiguration（API8）和 Improper Inventory Management（API9）往往借助从移动应用、Web 包或源代码中获取的凭据、路由或请求格式，更容易被发现或验证。
如何测试移动应用的后端 API 是否存在 BOLA？
反编译应用，了解其端点、标识符格式以及所有请求签名或加密方式。然后用一个账户创建对象，再用第二个账户读取、修改和删除这些对象，并重放应用的确切请求格式。对接受对象 ID 的创建端点重复上述操作。
轮换泄露的移动 API 密钥就够了吗？
这取决于密钥本身。有些移动 API 密钥本就设计为公开的，并按应用、平台或配额加以限制，因此仅仅暴露并不构成入侵。对于泄露的特权密钥，仅靠轮换是不够的，因为下一个构建版本会以同样的方式带上新密钥。应吊销并轮换该密钥，然后将其从客户端中移除，并由后端服务签发短期有效、按用户签发的令牌。
我们为什么要构建多资产测试？
我们一再看到，团队针对代码、移动应用和 API 分别运行不同的扫描器，再手动核对结果，而真正关键的攻击链却恰恰经由从客户端二进制文件中提取的凭据展开。
这就是我们构建 Multi-Asset Deep Agentic Scan 的原因：它通过一个闭环，把在客户端二进制文件中发现的令牌变成针对后端的线上测试，并且只报告它所复现的攻击链。
如果您想更全面地比较各类 API 测试工具，请参阅我们的2026 年 API 安全测试工具对比。如需了解多资产扫描能在您自己的移动应用和 API 上发现什么，请预约我们安全工程团队的演示。