API安全盲区：如何发现影子API与运行时异常调用

如今，企业应用越来越依赖API连接前端、移动端、合作伙伴和内部系统。API的数量随之快速增加，但安全团队掌握的资产清单往往没有同步更新。新接口已经上线，文档还没有补齐；旧版本停止维护，却仍在处理真实请求；一些测试接口和内部接口，也可能因为配置变化而暴露在非预期的网络范围内。

这种情况下，企业面对的API安全问题不只是“某个接口有没有漏洞”，而是能否回答几个更基础的问题：当前究竟运行着多少API？哪些接口没有纳入管理？谁在调用它们？请求行为是否符合原来的设计？

如果这些问题没有明确答案，再完善的安全策略也可能只是保护了已知资产而已。

影子API是什么？它是怎样形成的？

影子API通常指已经运行或能够被访问，却没有进入正式资产清单、安全策略或运维流程的接口。它不一定是开发人员私自创建的接口，也可能是在正常业务迭代中逐渐脱离管理的API。

例如，开发团队为了支持新功能快速增加了一个接口，但没有及时更新OpenAPI文档；应用已经升级到新版本，旧接口却因为部分客户端仍在使用而没有关闭；测试环境复制了生产数据，并通过临时域名对外提供访问；企业并购或系统交接后，原有接口缺少明确的负责人。微服务、容器和多云部署进一步加快了接口变化，也让人工维护清单越来越困难。

还有一些API并未经过统一网关。它们可能用于服务之间的内部通信，也可能部署在不同云、数据中心或合作伙伴环境中。安全团队如果只查看互联网入口或某一个API网关，就很难看到完整的API活动。

影子API真正的风险，在于它们长期处于安全团队的视线之外。接口可能没有经过身份验证检查、速率限制、数据分类和漏洞测试，也可能仍然使用旧组件或宽松的访问策略。

发现API只是第一步

建立API清单可以解决“有哪些接口”的问题，却不能直接判断这些接口是否正在被滥用。一个已经登记并配置身份验证的API，在运行过程中仍可能出现异常调用。

这些异常不一定表现为传统漏洞攻击。攻击者可能使用合法账号和正常格式的请求，持续读取超出业务需要的数据；自动化程序也可能按照接口规则执行，却以远高于正常用户的频率批量查询、注册或提交交易。

企业需要关注的运行时异常一般包括：

原本调用量稳定的接口在短时间内出现请求激增；
某个客户端开始访问过去从未调用过的端点；
正常用户很少使用的HTTP方法突然频繁出现；
未经身份验证的请求访问了本应受保护的接口；
单次请求或响应返回的数据量明显增大；
接口开始传输个人信息、支付数据等敏感内容；
API调用顺序偏离正常业务流程；
已废弃版本重新出现持续访问；
同一身份在短时间内遍历大量对象编号或账户信息。

因此，API安全不能只依赖静态文档或发布前测试，还需要持续观察真实流量，了解接口在生产环境中实际上是如何被使用的。

如何建立持续更新的API资产清单？

更可靠的API发现方式，是把设计阶段、发布阶段和运行阶段的信息结合起来，而不是完全依赖某一份人工表格。

首先，企业可以从代码仓库、API定义文件、API网关配置和开发平台中整理“计划存在”的接口。这部分信息能够说明API原本应当包含哪些端点、方法、参数和身份验证方式。

然后，应通过运行时流量观察“实际存在”的接口。将真实流量与OpenAPI定义、API网关清单和配置记录进行比对，就可以发现文档中没有记录的新端点、仍有流量的旧版本，以及绕过既有管理入口的接口。

对于外部暴露的应用，还可以通过授权的Web爬取或攻击面检查，识别前端页面和客户端实际调用的API。单一发现方式通常存在局限，代码分析、配置清单、外部观察和流量分析相互补充，才能减少遗漏。

发现端点后，还应为每项API补充必要的管理信息，包括：

所属应用和业务负责人；
生产、测试或开发环境；
API版本和生命周期状态；
允许访问的用户或系统；
身份验证方式；
是否处理敏感数据；
对外、内部或合作伙伴访问范围；
对应的安全策略；
停用或迁移计划。

API清单的价值不在于“登记过一次”，而在于能够随着流量和应用变化持续更新。

如何识别运行时异常调用？

识别异常调用之前，需要先了解正常行为。企业可以按API端点建立行为基线，观察常见的请求方法、参数结构、响应状态、调用频率、身份验证状态、客户端来源和数据类型。

有了正常行为基线，当接口出现明显偏离时，安全团队才能更快确定调查范围。例如，请求量上升并不一定意味着攻击，也可能来自营销活动或正常业务增长；但如果请求量上升同时伴随身份变化、对象遍历和敏感数据返回，就需要提高风险级别。

运行时分析还应该结合API定义进行验证。对于结构相对稳定的接口，可以根据OpenAPI规范检查允许的端口、方法、参数和数据格式，拒绝明显不符合定义的请求。对于业务变化频繁或难以完全用规则描述的场景，则需要结合行为分析、速率控制、身份信息和上下文判断异常。

需要注意的是，异常检测不能只看请求数量。API攻击经常利用正常功能和合法身份，真正值得关注的是调用对象、访问范围、操作顺序和数据结果是否符合业务逻辑。

发现影子API后应该怎样处理？

发现未知接口后，直接阻断并不一定是最稳妥的处理方式。部分影子API可能仍在支持重要业务，贸然关闭会影响合作伙伴、旧客户端或内部系统。

更合适的流程是先确认接口所属应用和负责人，再判断其业务用途、访问范围和数据敏感程度。经过确认后，可将接口分为需要纳管、限制访问、继续观察或计划下线等不同类别。

对于需要保留的接口，应补充文档、身份验证、速率限制、数据保护和运行时监测策略；对于已经废弃但暂时无法关闭的接口，可以缩小访问范围并加强监控；对于没有业务依据、存在明显风险的未知端点，则应在完成影响评估后限制或阻断访问。

API资产治理最终应形成闭环：发现接口，确认归属，评估风险，纳入策略，持续监测，并在不再需要时完成下线。只有发现而没有后续处置，API清单很快还会再次失去价值。

F5如何帮助企业减少API安全盲区？

F5将API安全纳入进从开发到运行阶段的完整保护过程。F5 Distributed Cloud API Security可结合代码仓库分析、运行时流量检查和外部Web爬取等方式发现并映射API端点，同时生成或使用OpenAPI规范，帮助企业识别未知接口、影子API和敏感数据流。

在运行阶段，该方案可通过持续流量监测建立行为基线，识别身份验证状态、异常活动和可疑请求，并结合WAF及API安全策略进行限制或阻断。企业可以将API发现、风险分析、运行时监测和保护策略放在相对统一的视图中，减少不同团队和工具之间的信息断层。

对于隔离网络、受监管环境或不适合向外部服务传输API数据的场景，F5还提供API Security Local Edition。根据F5当前官方文档，该产品在企业本地环境中运行，通过BIG-IP提供的HTTP元数据发现影子API、僵尸API、敏感数据流和身份验证缺口。Local Edition本身不直接处理或阻断业务流量，需要通过BIG-IP及相关安全策略执行保护动作。

不同产品和部署方式的实际可用范围、许可条件以及中国市场适用性，仍需根据企业环境和F5最新官方信息进一步确认。

从“看见接口”开始建立API安全能力

API安全的基础不是增加更多规则，而是先看清企业实际运行的API。静态资产清单只能记录某个时间点的情况，真实流量则反映了接口当前如何被访问、传输什么数据以及是否出现异常变化。

企业可以从关键业务应用开始，将API定义、API网关配置、代码信息和API运行时流量进行核对，逐步建立持续更新的资产清单。随后再通过行为基线、规范验证、身份分析和风险分级，把API发现转化为实际保护能力。

当企业能够持续回答“有哪些API、由谁负责、谁在调用、调用是否正常”时，影子API和异常调用才不会长期停留在安全盲区。

点击了解更多关于Web应用和API保护解决方案的相关信息。

常见问题

1 ) 什么是Web应用与API 保护（WAAP）？它与传统的Web应用防火墙（WAF）有何不同？

A：WAAP是一种融合式的主动应用防护方法，以WAF为核心，并将API安全、Bot管理与DDoS缓解整合为一体化解决方案。传统WAF主要聚焦于缓解应用层漏洞被利用的风险（例如注入攻击和应用层DoS）。WAAP将覆盖范围扩展到API发现、检测与防护、自动化威胁缓解（Bot与自动化攻击），以及抵御DDoS攻击的韧性能力。与分别管理多个独立的点产品相比，WAAP有助于减少安全缺口并降低运营开销。

2) 在混合云或多云环境中，保护RESTful API 的最佳实践有哪些？

A：可视性是维护安全API清单的关键起点。借助更高的可视性，您可以识别已知、未知以及影子API，并结合WAF与API安全控制实现更有效的验证与防护（在可行情况下尽量采用基于Schema或API定义的验证，同时配合行为监控与异常检测）。整体化安全能够在混合多云部署中实施一致的策略，使敏感数据暴露与错误配置的监控更容易，并在设置使用阈值方面提供更强的精细控制，从而降低滥用与DoS风险。集中式管理与集成监控有助于避免因工具蔓延而产生的安全与运维缺口。

3) WAAP解决方案如何检测并阻断BOLA攻击及其他针对 API 的威胁？

A：BOLA（Broken Object Level Authorization，对象级授权失效）是一种API特有的威胁，攻击者会利用对对象的未授权访问发起攻击。 WAAP通过将WAF强制执行与更深入的API安全能力相结合来应对这一问题：对端点进行发现/清点、持续的流量监控、行为分析与异常检测，用于识别误用、滥用以及访问违规。 WAAP还可减少盲区：当API与API之间的流量未经过传统边界WAF时，依然能在不同接口与环境中提供一致的运行时防护。