应用安全平台API安全能力评测：与专业API安全网关的边界与互补

开头：一个被API安全问题搞到通宵的真实场景

今年攻防演练前夜，我们收到一个高危预警：某个对外公开的API存在越权漏洞，攻击者可以直接遍历订单数据。我连夜联系安全厂商，对方很自信地说他们的应用安全平台“全面覆盖API安全”。结果呢？加了Agent、配了策略，第二天红队依然通过另一个没被“发现”的API端点打了进来。

问题出在哪？应用安全平台确实能检测一些API风险，但它的API发现能力主要依赖运行时流量分析和代码审计，那些没有流量的“僵尸API”、未在网关注册的“影子API”，它根本看不见。这就是典型的能力边界问题——不是平台不行，是它不适合干这个活。

作为安全架构师，你需要搞清楚：应用安全平台能做哪些API安全的事情？哪些必须靠专业API网关？两者如何分工配合？ 这篇文章是我调研和实战后梳理的答案。

一、先搞清楚三款产品的定位

在讨论边界之前，先把三个容易混淆的产品拆清楚：

1. API网关（如Kong、APISIX、Azure API Management）

API网关的本质是流量入口和控制点。它的核心职责是：路由、认证、限流、协议转换。安全只是它的一部分功能。

网关能做的安全事儿：

• 身份认证（JWT、OAuth、API Key）
• 静态限流（单IP每秒100次）
• IP黑白名单
• 基本的请求过滤

网关做不到的：

• 检测BOLA（越权）这类业务逻辑漏洞
• 识别攻击者的行为模式（比如慢速撞库）
• 发现未在网关注册的“影子API”
• 检测API响应中的数据泄露

2. WAF（Web应用防火墙）

WAF是网络边界的安全过滤器。它基于规则检测HTTP/HTTPS流量中的攻击特征。

WAF能做的：

• SQL注入、XSS等传统Web攻击检测
• 虚拟补丁
• 简单的地理围栏

WAF的短板：

• 缺乏API上下文——看不懂API的Schema，不知道哪个参数是敏感的
• 对API专有攻击（如BOLA）检测能力弱——这些攻击的请求看起来“正常”，WAF没法区分
• 无法做行为分析——单次请求正常，但多次请求组合起来就是攻击

3. 应用安全平台/API安全平台

这类平台（包括我们之前选型的几维安全、以及Salt、Noname等）是专门为API/应用设计的安全大脑。它的核心能力是：发现API资产、分析行为异常、检测业务逻辑攻击、提供修复建议。

能做的：

• 持续发现API（包括运行时和代码仓库）
• 构建API Schema基线
• 检测BOLA、批量分配、业务逻辑滥用
• 行为分析和异常检测
• 与开发流程集成（Shift Left）

不能做的：

• 网络层面的流量管理（负载均衡、路由）
• 高性能的实时限流（它的限流是“策略性”的，不是“网关级”的）
• 替代网关的认证鉴权

二、应用安全平台的API安全能力：强在哪？弱在哪？

我们重点评测了几维安全的API发现模块，同时对比了Salt和Invicti的方案。以下是真实的发现：

2.1 强项：深度检测和行为分析

API发现能力

应用安全平台通常通过多种方式发现API：

• 流量分析：镜像或Agent采集流量，解析出API端点
• 代码分析：扫描代码仓库中的路由定义、Swagger文件
• DAST扫描：主动爬取和测试API

几维安全在这个环节表现不错：我们部署后一周内发现了47个未被网关记录的API端点，其中3个是已下线的业务残留（“僵尸API”），2个是开发测试忘记下线的接口。这些如果没有平台发现，就是攻击者的突破口。

BOLA检测能力

这是API独有的高风险漏洞。传统WAF和网关完全防不住。几维安全的做法是：学习正常用户的API调用序列，建立行为基线，当检测到某个用户尝试访问其他用户的资源ID时，触发告警。

Schema一致性检测

Salt Security在这个领域做得比较深入：动态比对运行时的API参数和OpenAPI文档，发现不一致就告警。比如文档说参数是枚举值，但实际收到了任意字符串——这可能就是攻击者在探测。

2.2 弱项：边缘视图的盲区

问题一：看不见没流量的API

这是最致命的短板。应用安全平台的API发现，无论是DAST还是运行时流量分析，都需要“有流量”才能发现。

但实际情况是：

• 影子API：业务部门自己搭建的API，没有经过网关，也没有被扫描到
• 僵尸API：已下线的服务，但仍然暴露在公网
• 低频API：月度调用量只有几次，平台可能根本采不到样本

我们的实测数据：几维安全发现了47个未注册API，但后来用云厂商的边缘流量分析又发现了19个——这些API在过去一个月内没有任何调用记录，但确实验证了可以访问。

问题二：缺乏实时流控能力

应用安全平台的限流是“策略层”的：它检测到异常后，通过API调用网关的接口去执行限流，或者直接返回429。这个链路有延迟，无法应对突发的高频攻击。

专业API网关的限流是“数据层”的：在内存中维护计数器，毫秒级响应。

问题三：对加密流量的依赖

大部分平台的流量分析依赖解密后的HTTPS流量。这意味着要么你把私钥给平台（有合规风险），要么在网关之后部署（那网关之前的流量就看不见）。

三、内外网API分层防护：我的架构建议

基于上面的能力边界分析，我们最终采用的架构是“边缘网关+内网平台”分层防护。核心思路：网关管“大门”和“流量”，平台管“内鬼”和“逻辑”。

3.1 架构图

公网 → 边界WAF/网关 → 内网负载均衡 → API网关（内部） → 后端服务                              ↓                      应用安全平台（旁路流量镜像）                              ↓                      异常告警 → 网关策略调整

3.2 分层职责

第一层：边界WAF/网关（面向公网）

负责：

• SSL卸载和TLS策略
• 基础的攻击特征检测（SQL注入、XSS）
• DDoS防护和粗粒度限流（单IP限流）
• 地理围栏

部署位置：DMZ区，直接暴露公网

这一层不要求深度API理解，但要扛得住大流量和基础攻击。

第二层：API网关（面向内网）

负责：

• 服务路由和负载均衡
• 认证鉴权（JWT验证、API Key校验）
• 精细化限流（按用户、按API、按时间段）
• 协议转换和请求/响应改写

部署位置：内网，业务集群入口

这一层是执行层——收到应用安全平台的指令后，执行阻断或限流。

第三层：应用安全平台（旁路分析）

负责：

• 全量API发现（接入网关流量镜像 + 代码仓库扫描）
• Schema学习和异常检测
• BOLA、批量分配、业务逻辑攻击检测
• 敏感数据暴露检测
• 生成阻断策略，推送给网关执行

部署位置：内网，流量镜像端口

这一层是大脑——不直接处理请求，只分析和决策。

3.3 为什么这么分层？

原因一：性能和深度不可兼得

API网关要处理每秒数万请求，不能做复杂的AI推理。应用安全平台的检测模型很重，不适合在线路径。分层后各司其职。

原因二：边缘视图和内网视图互补

边缘网关看到的流量更全（包括公网进来的所有请求），但对业务上下文理解浅。应用安全平台拿到的是解密后的、有完整业务语义的流量，分析更准。两者结合，既能发现边缘的影子API，又能做深度检测。

原因三：安全与业务的解耦

网关变更有审批流程，改一次限流策略可能要一周。应用安全平台可以快速调整检测模型，不影响业务。如果安全能力直接嵌入网关，运维成本极高。

四、实战配置清单

4.1 应用安全平台配置要点

1. 开启双向API发现

   • 流量分析（接入网关镜像）
   • 代码仓库扫描（GitLab/Jenkins集成）

2. 配置敏感数据识别规则

   • 身份证、手机号、银行卡正则
   • 响应体中的敏感字段脱敏检测

3. 建立业务基线

   • 至少学习2-4周的正常流量
   • 标记“正常用户”和“正常调用序列”

4. 告警推送至网关

   • 通过Webhook将阻断策略推送到网关
   • 建议策略：可疑IP临时加入黑名单（15分钟）

4.2 API网关配置要点

1. 开启全量访问日志

   • 输出到日志平台，应用安全平台可以消费

2. 配置精细化限流

   # 示例：按用户ID限流limit_req_zone $jwt_claim_sub zone=user_limit:10m rate=10r/s;

3. 预留策略接口

   • 暴露一个内部API，允许安全平台动态调整黑名单

4. 启用JWT强制校验

   • 所有API都必须验证JWT，不允许匿名访问

五、FAQ：关于API安全的5个高频问题

Q1：应用安全平台能替代API网关吗？

不能。网关负责路由、负载均衡、认证，这些和安全无关。应用安全平台不做流量转发，两者是互补关系。

Q2：我们已经买了WAF，还需要API安全平台吗？

如果你们的API只是简单的CRUD接口，WAF可能够用。但如果API涉及业务逻辑（订单、支付、用户信息），WAF防不住BOLA这类专有攻击。我们就是因为WAF被绕过才上的平台。

Q3：检测到API攻击后，如何响应？

推荐半自动化：平台检测到攻击后，自动推送到网关的“待确认黑名单”，安全人员确认后一键生效。全自动拦截风险太大，容易被利用做拒绝服务。

Q4：内部API（East-West流量）需要保护吗？

需要。内部API往往权限更大、数据更敏感。我们之前被红队打穿的就是内部API——攻击者拿到一个低权限账号后，发现某个内部API没做校验，直接提权。建议内网API也接入应用安全平台做行为监控。

Q5：平台部署会影响API延迟吗？

如果采用流量镜像（旁路），不会影响。如果是串联部署（流量先过平台再过网关），会增加5-10ms延迟，我们不推荐这么做。

结尾：我的架构选型结论

调研完API安全的能力边界后，我们没有退掉任何现有设备，而是做了架构调整：

• 保留网关：继续负责路由、认证、限流这些“本职工作”
• 保留WAF：继续在边界扛DDoS和基础攻击
• 新增应用安全平台：做API发现、BOLA检测、行为分析

三者不是替代关系，是分层配合。网关是“门禁”，WAF是“安检仪”，应用安全平台是“监控室里的AI分析员”——各干各的，缺一不可。

如果你也在规划API安全方案，我的建议是：先盘点你现有的能力缺口，是缺“发现”还是缺“检测”还是缺“响应”？然后按照“边缘网关+内网平台”的思路做分层设计，而不是试图用一个工具解决所有问题。