前面我们一直在 APP 这个”壳”上做文章，但真正处理业务、存数据的是它背后的 API。可以说，现代系统的命门不在界面，而在接口。一个 APP 再安全，只要后端 API 有越权、能拖库，用户数据照样裸奔。这一篇先不急着打，而是把 API 的”种类”认全——不同形态的接口，攻击面完全不同。

本文仅用于你对自有或已授权的系统做 API 安全测试。对第三方 API 未授权测试可能违反法律法规与服务条款。

为什么 API 是重灾区

几个原因让 API 成了黑客最爱：

• 它直接连数据库：很多接口就是”参数进、数据出”，少了一层界面过滤。
• 逻辑复杂、边界多：鉴权、限流、参数校验任何一处漏了就是洞。
• 文档泄露：Swagger、Postman 集合、前端 JS 里常常把接口清单和参数写得清清楚楚。
• 自动化友好：接口是给程序调用的，天然适合用脚本批量打。

OWASP 专门出了 API Security Top 10，说明这已经是独立的安全领域，不再是 Web 安全的附庸。

REST：最常见的那一种

REST 用 URL 表示资源、用 HTTP 方法表示动作（GET 查、POST 增、PUT/PATCH 改、DELETE 删）。今天绝大多数 APP 后端都是 REST。

GET /api/v1/users/1001 HTTP/1.1
Host: api.xxx.com
Authorization: Bearer eyJhbGciOi...

REST 的攻击面集中在：URL 里的 ID 越权（改 1001 看别人）、方法滥用（本该 GET 的接口能不能 DELETE）、 token 失效、参数注入。它简单，所以暴露面也直白。

GraphQL：一个接口查所有

GraphQL 反其道而行：客户端自己写”查询语句”决定要什么字段，服务端一个 /graphql 端点接收。

query {
  user(id: 1001) {
    name
    email
    friends { name }
  }
}

灵活是优点，也是风险：

• 内省（Introspection）：默认开启时，攻击者能查到整套 schema，等于拿到接口文档；
• 过度查询：客户端能要到本不该给的字段（比如 email、passwordHash），即”过度数据暴露”；
• 深度查询/批量查询 可造成拒绝服务（一次查几千层嵌套）。

测 GraphQL，先试 Introspection 能不能开，再试能不能要到敏感字段、能不能构造超复杂查询把服务打挂。

SOAP：老派但仍在

SOAP 用 XML 信封、WSDL 描述接口，常见于银行、政府老系统。它的攻击面偏 XML 系：XXE（外部实体注入）、XML 注入、重放攻击。今天新系统少见，但测老系统绕不开。

<soap:Envelope>
  <soap:Body>
    <GetUser><id>1001</id></GetUser>
  </soap:Body>
</soap:Envelope>

gRPC：高性能的二进制接口

gRPC 用 Protobuf 定义接口、HTTP/2 传输，性能好，微服务间常见。它二进制、有 schema，看起来”黑盒”，但：

• .proto 文件一旦泄露，接口和字段全暴露；
• 工具如 grpcurl 能像 curl 一样调用，前提是知道 schema；
• 鉴权、越权逻辑照样可能写错。

测 gRPC 难点在”要先有 proto”，所以信息收集阶段找 .proto、找反射（reflection）是否开启是关键。

WebSocket：双向长连接

WebSocket 建立一次连接后双向实时通信（聊天、行情、通知）。它的风险：

• 建立握手是 HTTP，可能继承也可能绕过鉴权；
• 消息帧里同样有越权、注入问题；
• 没有天然限流，易被洪水式消息打挂。

测 WebSocket 要用能抓帧的工具（Burp 的 WebSocket 历史、或者自己写个小客户端），重点看”换了个连接通道，鉴权还生效吗”。

RPC / 内部接口：被忽略的暗门

很多系统还有内部 RPC（如 Thrift、Dubbo）或”仅供内部调用”的接口。它们常被开发者认为”外网访问不到”而疏于防护，可一旦被 SSRF、被误暴露，就是直通数据库的后门。测的时候别只盯公网 REST，内部接口同样是资产。

对照 OWASP API Top 10

认识了种类，再看风险地图。OWASP API Top 10 几个高频项：

• BOLA（对象级越权）：改个 ID 看到别人的数据，API 头号风险。
• BFLA（功能级越权）：普通用户调了管理员才该用的接口。
• 过度数据暴露：接口返回了它不该给的字段。
• 资源缺乏限流：能被无限调用、爆破、拖库。
• 批量分配（Mass Assignment）：传了不该传的参数（如 isAdmin=true）被服务端照单全收。
• SSRF：API 去请求攻击者指定的内网地址。
• 安全配置错误：Introspection 开着、详细错误暴露、CORS 过宽。

这些风险在不同接口形态上表现不同，但根子都是”信任了客户端、漏了服务端校验”。

怎么快速认出目标用哪种 API

信息收集阶段几招：

• 抓包看请求：/graphql 基本是 GraphQL；XML 信封是 SOAP；content-type: application/grpc 是 gRPC；Upgrade: websocket 是 WebSocket；其余 REST 居多。
• 翻前端 JS、Swagger（/swagger.json、/v2/api-docs）、Postman 导出。
• 报错信息常暴露框架（Spring、Express、Django），顺带提示接口风格。

建立 API 资产视角：攻击者眼里的地图

站在攻击者角度,API 不是一个个孤立的接口,而是一张”资产地图”:哪些是对外公开的、哪些要登录、哪些只有管理员能调、哪些连着数据库、哪些能出网。谁能把这张图画得最全,谁就离漏洞最近。所以信息收集阶段挖 Swagger、翻 JS、找 Postman,本质上就是在”画地图”。作为防御方,反过来要想:你的地图是不是也该自己先画一遍?很多团队根本不知道自己对外暴露了多少接口,直到被扫到才知道有那么个 forgotten API。

这也是为什么”API 网关”和”接口资产管理”越来越重要。把流量统一收口到网关,你才能看到全量接口、统一加鉴权与限流、统一审计。那些散落在各微服务、各老系统里的”暗接口”,恰恰是最容易被漏掉、也最容易被打穿的地方。攻击者最爱找的,就是开发自己都快忘了的那一个。

还有一点认知升级:API 安全不能只靠”加个 token”。token 解决的是”你是谁”,解决不了”你能不能看这条数据”。BOLA 这类越权,持有合法 token 照样能打。所以资产视角之外,还要有”每个接口都要回答三个问题”的习惯:调用者是谁、他有没有权限碰这个对象、这次操作该不该被限流。这三个问题答不全,接口就不该上线。把 API 当成需要持续盘点的资产,而不是写完就忘的功能,安全水位会明显不同。

再补一个容易被忽略的视角:API 的”版本”也是攻击面。很多系统同时跑着 /api/v1、/api/v2 甚至更老的版本,旧版本常常没人维护、校验更松,却还对外提供服务。攻击者专挑老版本打,因为新版本修了的逻辑洞,老版本可能原样留着。所以信息收集时,把各版本接口都列出来逐个比对,往往能在”被遗忘的 v1”里找到已被新版本修掉的同类漏洞。版本管理不是运维小事,它直接关系攻击面大小。测 API,版本号一定要扫全。

另外,内部接口和外部接口的边界也值得强调。很多团队认为”内网接口碰不到”就疏于防护,可一旦攻击者通过 SSRF 或一台沦陷的内网机器转进来,这些无鉴权的内部接口就成了直达数据库的高速公路。不要把”外网访问不到”当成安全设计,那只是暂时的运气,不是保障。内部接口的防护标准,应当和外部接口一视同仁,因为边界从来都比想象中更容易被击穿。

这一篇你该记住的

• API 是现代系统命门，OWASP 已单列 API Top 10。
• REST 看 ID 越权与方法滥用；GraphQL 防 Introspection 泄露与过度查询；SOAP 防 XXE；gRPC 找 proto 与反射；WebSocket 验通道鉴权；内部 RPC 是暗门。
• 高频风险：BOLA、BFLA、过度暴露、无限流、批量分配、SSRF、配置错。
• 根因都是”信了客户端、漏了服务端校验”。
• 认接口种类靠抓包特征 + 翻文档（Swagger/JS/Postman）。

种类认全了，下一篇我们进入实操：具体用哪些技巧去打这些 API，从信息收集到各类漏洞利用逐一拆解。