文章总结： 该文系统梳理2026年API渗透测试全流程，从端点发现、API地图绘制到十大漏洞类别实战，重点覆盖BOLA/IDOR、JWT与OAuth配置缺陷、批量赋值、限流缺失、竞态条件、SSRF、注入、GraphQL及AI/LLM接口风险，指出UUID不等于访问控制、提示词注入成新攻击面，并给出服务端授权、白名单校验、限流与API资产清单等防御建议。 综合评分： 78 文章分类： 渗透测试,WEB安全,AI安全,安全工具,实战经验

2026年API攻击指南：从基础到前沿漏洞

幻泉之洲

2026年9月12日 12:08 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

五年时间，API安全格局变了天。GraphQL成了标配，OAuth遍地开花却漏洞百出，AI驱动的接口带来了全新的攻击面。BOLA依然是王者，但玩法多了不少。这篇文章把2026年API渗透测试的完整思路、工具链和十大漏洞类别一次讲清楚，附带大量实操细节，适合有经验的测试者。

距离我上次写API攻击指南已经过去五年了。2021年那篇是和Farah Hawa合作的，当时API在开发圈已经很火，但多数安全内容还在假设你在测试一个服务端渲染的网页应用。现在这个转变彻底完成了——2026年，API就是应用本身。浏览器、移动端、智能电视、合作伙伴集成、调用工具的AI代理，全都只是客户端，背后打的都是同一批接口。

所以这是2026版。2021年说的很多东西依然有效，我会重复一遍，省得你翻旧帖子。但攻击面在几个新地方长了牙：GraphQL到处都是，OAuth流程变得更复杂也配置得更烂，还有一整批AI驱动的API冒出来——这在我们上次写的时候还完全不存在。

API到底是什么，为什么总是出问题

API（应用程序编程接口）就是一份契约，规定两个软件怎么在网络上对话。用Web安全的术语说，你打开一个现代应用，数据加载但页面不刷新——那就是前端在后台向API发请求然后渲染返回结果。现在大多数都走JSON over HTTP，但XML、SOAP、gRPC和GraphQL还能碰到。

API为什么是攻击者的富矿？因为大部分敏感数据和功能恰好都通过它暴露。你可以直接调用它，任何顺序，任何值，跳过前端原本应该执行的所有检查。这份指南里几乎所有API漏洞都归结于同一个缝隙：“应用预期怎么被使用”和“实际能被怎么使用”之间的那条沟。

测试API的前置准备

工具不多。一个拦截代理，加上一个重放和构造请求的东西，能覆盖大部分场景。

• 拦截代理。

  Burp Suite还是默认选择。Caido从2021年起成了真正有竞争力的替代品，Burp用着觉得重可以试试。两者都夹在客户端和服务器之间，让你读、改、重放每一个请求。

• 请求构造工具。

  Postman拿来导入集合和发请求还行。Bruno和Insomnia是更轻量的开源选项，势头不错。无论选哪个，把代理设置指向127.0.0.1:8080让流量过Burp或Caido，再导入对应的SSL证书。

• 内容发现。

  我个人用ffuf和feroxbuster做快速模糊测试，想专门做API感知的路由发现时用kiterunner，词表用Assetnote的——API路径和参数名方面目前仍然是标杆。

• 记笔记的习惯。

  API端点太多、状态太多。记录哪个token属于哪个用户，见过哪些ID，哪些端点还没试。API可以非常复杂，最好的漏洞通常来自系统化地认真测试每一个端点。

▲ Burp Suite仍是HTTP流量代理和手动API测试的黄金标准。

第一步：找到API并绘制地图

开始挖掘之前，先把整个API结构搞清楚。

读前端JavaScript

单页应用把后端的完整地图藏在客户端代码里。前端JS塞满了端点路径、参数名，有时候甚至还有硬编码的密钥。把JS拉下来，搜索/api/、fetch(、axios和路由片段。AI在这里能帮上大忙——写这篇文章时，用gpt-5.6-sol或claude-opus-5这样的前沿模型配合终端里的Claude Code或Codex，能帮你拉取并分析客户端JS，构建API地图。

代理移动应用

如果存在移动端，也值得代理一下。移动客户端往往调用比Web应用更丰富或更旧的API版本，是未公开端点的常见来源。把应用流量导到你的代理里，观察它调了什么。

找到并阅读文档

Swagger / OpenAPI规范、GraphQL schema、公开的Postman集合。/swagger.json、/openapi.json或/api-docs一次就能把整张地图交给你。

枚举版本和非生产环境路由

旧版本很少获得和当前版本一样的安全关注。试/api/v1/、/api/v2/、/api/beta/，把主机名或路径换成非生产环境的：dev、qa、staging、test、uat、preprod、internal。一个已废弃的v1端点跳过了v3版本新加的检查——这是经典发现，OWASP现在把它归在“不当资产清点”下。

GraphQL内省查询

如果目标说GraphQL，试内省查询。内省开着的时候（经常如此），服务器会返回完整schema：每一个类型、查询、变更和字段。一个请求拿全图。GraphW00f（指纹识别）、InQL或graphql-cop（审计）能加速这个过程。有时即使内省被禁用，你依然能靠错误信息把整个API摸出来。有些GraphQL实现会给出有用的线索——比如你查“user”，它回“你是说users吗？”。这种情况下可以用Clairvoyance这样的工具画出整个API。

值得投入时间的漏洞类别

OWASP维护着一份专门的API安全Top 10（当前版本是2023年的列表），是个不错的骨架。下面挑真正有回报的讲，每个从头解释，并标注2021年以来有什么变化。

1. 对象级授权缺失（BOLA / IDOR）

这个是大头。2021年也是大头，那时叫IDOR。说实话不知道为什么改了名字。它仍然霸占OWASP API列表第一，是最值得搞懂的漏洞类型。

概念很简单：端点上有一个对象标识符，比如GET /api/v1/invoices/1234，服务器把对象返回，但没检查你有没有权限看它。把1234改成1235，如果你拿到了别人的发票，恭喜你发现了BOLA（也就是IDOR）。服务器确认了你的身份（知道你是谁），但没校验这次具体的请求（没确认这个对象属于你）。

怎么测：注册两个账号，用A账号执行操作，然后把A的请求用B的token重放、对象ID还是A的。如果B能读或改A的数据，一个漏洞就到手了。到处找ID——路径里、查询参数里、请求体里、请求头里，无处不在。

2021年以来的变化：很多开发者学聪明了，弃用递增整数ID，改用UUID，以为随机性等于安全性。并非如此。UUID是标识符，不是访问控制，RFC规范里自己都这么写。如果你能从任何地方搞到UUID（共享链接、另一个泄露信息的端点、搜索结果），BOLA照样可利用。不要因为ID看起来猜不到就跳过那个端点。大多数人（黑客和开发者都一样）忽略的一个点是：UUID并不保证随机。UUID RFC规范里明确说了：

▲ 自己去RFC规范第8节看：https://www.rfc-editor.org/info/rfc9562/#section-8

2. 身份验证缺陷

JWT实现缺陷

JSON Web Token是API携带身份的标准方式。JWT是三个base64段用点连接：头部、载荷和签名（header.payload.signature）。头部声明用什么算法签名，载荷里面有用户ID之类的声明，签名防止你篡改载荷。2026年经典攻击依然有效，因为人们还在反复配置错这些库：

• alg: none。

  把算法设成“none”，剥掉签名。服务器如果接受，意味着它信任未签名token，你可以在载荷里放任何内容。

• 弱密钥。

  HS256 token用共享密钥签名。如果密钥弱（secret、changeme、泄露的值），你可以用hashcat在离线场景爆破，然后为任意用户伪造合法token。

• RS256降级HS256。

  RS256用私钥签名、公钥验证。把头部改成HS256，然后用服务器的公钥作为HMAC密钥签名token——天真的库会验证通过，因为它用的就是那个随便给人的公钥。

• 忽略过期时间。

  检查旧token是否还有效。相当多实现从未真正验证exp声明，token因此永不过期。

我实际写了一个JWT Hacking工具包，能帮你跑这些测试和构造载荷：https://hakluke.com/jwt-hacking

OAuth和OIDC配置错误

这些比较新，但突然到处都是。2021年我们几乎没碰OAuth，到2026年你隔三差五就能见到。流程极其复杂，因此极其容易搞砸。第一要查的是开放的redirect_uri处理——可以把授权码偷走的那种。接着查缺失state参数（登录流程上的CSRF），以及不轮换、不过期的refresh token。一个马虎的重定向校验就能给你完整账户接管。想深入了解主要攻击类型，可以看PortSwigger Web Security Academy的OAuth2实验室。

3. 对象属性级授权缺失（批量赋值 + 数据过度暴露）

OWASP把2021年的两个概念合并了。数据过度暴露指API返回了不该返回的东西。比如应用本意只是显示用户名字，但为此它调用的端点把“passwordResetToken”、“creditCardNumber”或其他PII也塞在了JSON响应里。前端可能不渲染这些字段，所以一定读原始响应，别看渲染后的页面。

批量赋值是反过来的问题。你发送额外字段，API照单全收。如果更新个人资料的接口接受一个包含name和email的JSON，试试加上其他可能和用户关联的字段，比如”role”: “admin”或”verified”: true，看它会不会存进去。自动把请求体绑定到数据库对象的框架特别容易中招——而大多数现代框架正是这么做的！

4. 无限制资源消耗和竞态条件

2021年我们管前面的部分叫“缺少速率限制”，但“无限制资源消耗”更贴切，因为它覆盖的东西广多了。没有速率限制意味着你可以暴力破解凭证和OTP、枚举用户、高速抓数据、用昂贵的端点消耗目标成本（每次SMS、邮件或LLM调用花的都是真金白银）。用Burp Intruder或ffuf能快速检查有没有任何限流措施。

竞态条件更微妙，而且至今被低估。如果一个端点先检查条件、再执行操作，两步之间是分开的，同时发送大量请求就能钻检查和操作之间的空子。这个概念有时叫“TOCTOU”——检查时点和使用时点之差。教科书案例是同一个一次性折扣码或礼品卡同时兑换一百次，在“已使用”标志写入之前全部成功。Burp内置的“分组并行发送”（单包攻击）让2026年做这个测试比2021年用Turbo Intruder脚本轻松太多了。只要涉及钱或有限资源，就去测。

5. 功能级授权缺失

BOLA是关于对象的（我能不能看你的发票）。这个是关于动作的（我能不能调用管理员功能）。普通用户往往还能访问特权端点，只是UI把按钮藏起来了，服务器端根本没管权限。

测试方法是拿一个管理动作，抓请求，换低权限token重放。AI做这事出奇地好——我手动测试用Burp扩展Autorize，它在所有拦截的请求上自动换token。还可以试试翻转HTTP方法：一个端点可能拒绝对/api/users的GET请求，却欣然接受DELETE /api/users/5或PUT。换动词（GET、POST、PUT、PATCH、DELETE）是个两分钟的检查，能找到真漏洞。

6. 服务端请求伪造（SSRF）

SSRF就是让服务器替你向不该访问的地方发请求。任何接受URL的API参数都是候选：从URL抓图片的功能、webhook配置、文件导入器。把它指向http://169.254.169.254/（云元数据）、http://localhost/admin或内网主机名，看服务器通不通。云环境里对元数据端点做SSRF能泄露凭证、拿到整个账户权限，这就是它爬上OWASP列表单独占位的原因。

这里说一句：我见过太多人因为能让服务器向一个Collaborator实例发出HTTP请求就报告SSRF。这本身不是漏洞，很多Web应用的正常功能就需要这样。只有当出现真实安全影响时才算漏洞——比如能调用敏感内部端点、打进内网、从元数据端点抓云厂商凭证。

7. 注入（SQL、NoSQL、命令）

注入历史悠久但没死。API接收你的输入，不加处理就把它丢进查询或shell。在JSON API里注入藏在你想不到的地方，因为开发者以为是字符串的字段完全可以携带攻击载荷：

{“scope”: “SELECT sleep(10)”}  // 通过时间延迟的盲SQL注入 {“filter”: {“$gt”: “”}}        // NoSQL操作符注入 (MongoDB) {“filename”: “x; cat /etc/passwd”}  // 命令注入

NoSQL注入在2021年没被提及，现在该补上了，因为文档数据库普及太多了。攻击方式是注入$ne、$gt或$regex这类查询操作符来绕过认证或导出数据，而不是注入SQL语法。

8. GraphQL特定问题（2026年新增）

GraphQL没出现在2021版指南里，现在必须提。GraphQL API暴露的是单个端点（通常是/graphql），客户端通过它请求它想要的字段，而不是一堆REST端点。这种灵活性催生了专属漏洞：

• 内省未关闭

  把完整schema送到攻击者手里，上面讲过。

• 嵌套查询拒绝服务：

  GraphQL允许你用循环方式请求关联对象（书的作者写的书的作者写的书……）。一个深嵌套查询能让服务器在极小的请求下做巨量工作。查询深度和成本限制是防线——而且经常没配。

• 字段级授权：

  一个查询可能触及多个对象，授权必须在每个字段的resolver上执行，而不是在端点层面。漏掉一个你就有了GraphQL版的BOLA。测试时在单个字段层面操作，别只看顶层查询。

• 批量攻击：

  GraphQL可以在一个请求里接收多个操作。登录或OTP验证这类东西，一次HTTP请求发几百个尝试就能绕开速率限制。

9. 敏感业务逻辑的无限访问（业务逻辑）

有些滥用根本没破坏技术控制，它只是以业务从未预期的规模或顺序滥用合法功能：脚本扫空限量库存、刷推荐奖金、通过“推荐”端点抓完整个商品目录。这类漏洞需要你理解这个流程设计的初衷，然后问“如果我做一万次会怎样？或者打乱顺序呢？”人的判断在这里至关重要，扫描器发现不了，因为它需要理解业务。

10. AI和LLM驱动的API（全新类别）

这个类别在2021年根本不存在。现在很大一部分新API把用户输入传给语言模型，或者调用模型驱动的“工具”和“函数”。这开了一个前所未有的巨大攻击面：

• 提示词注入：

  如果端点把你的输入塞进模型提示词，你说不定能覆盖它的指令、提取系统提示词或让它干出格的事。如果模型能调用函数（发邮件、查询数据库、调另一个API），一次成功的注入就能变成真实操作——自然语言版的SSRF、注入和提权。

• 无限制消耗：

  模型调用很贵。不限制提示词大小和请求频率的端点就是直通目标云账单的管道，是前面速率限制问题的高价版本。

• 过度权限：

  模型接入了工具时，检查那些工具能做什么，以及你的输入能不能把它们引到预期范围之外。

什么没变，什么变了

如果你读过2021年的指南，这是最小变更清单。

依然成立的：

BOLA/IDOR仍然是王者。JWT配置错误偶尔还能用。未公开端点、旧API版本和staging主机依然是软目标。速率限制大多数时候还是缺。拦截代理加请求构建工具依然是核心装备。最核心的思维——API会允许你做UI永远不会做的事——依然成立。

2026年新增或规模剧增的：

GraphQL成了主流，带着自己的漏洞类别。OAuth/OIDC流程无处不在且普遍配错。NoSQL注入随着文档数据库扩散而愈发重要。竞态条件因为单包攻击变得极易测试。全新的AI驱动端点出现，提示词注入和无边界的消耗是头条风险。OWASP也在2023年重组了API Top 10，把旧类别合并、把SSRF和资产清点往上提，这和我们实测试的结果一致。

工作流本身也变了。现在AI是一个黑客工作流程里的大头，前沿模型在合适的引导下能自主完成大量测试。

高效测试的路径

面对一个API，我的流程大体是这样。

很多API又大又复杂，准备工作很重要。先把整个攻击面画出来，顺手记下每个对象ID和token，然后一个漏洞类别一个漏洞类别地扫过所有端点，再换下一个类别。一个团队如果在一个端点上搞错了BOLA，通常好几个端点都有同样的问题。自动化做机械化的部分（发现、模糊测试、JWT检查），把人的注意力留在授权和业务逻辑上——那里是扫描器沉默、真正有趣的漏洞所在的地方。

最重要的就是有章法地测试，确保系统化地覆盖每一个端点和参数。

给你的API做防御

如果你站在防守方，修复方案比攻击手段朴实多了。归根结底还是那套老生常谈的基础安全卫生，外加几个现代变化。

在每一个请求、每一个对象上强制执行服务端授权，永远别因为ID难以猜测就信任它。输入验证用白名单而不是黑名单。按用户、IP和端点做速率限制，把昂贵操作（短信、邮件、模型调用）当作值得保护的资源。维护准确的API、版本和环境清单，退役不需要的以减少暴露。生产环境关闭GraphQL内省并限制查询深度和成本。还有，持续测试——因为每次发版，攻击面都在变。

AI现在也站在防守方这边了——你可以在两次渗透测试之间用AI持续测试系统、验证用户角色之间的信任边界，并获得实时建议。

写在最后

API渗透测试的核心逻辑自2021年以来没有太大变化：找到端点，理解它们本该做什么，然后做点他们计划之外的事。

变了的是攻击面的规模和形状。GraphQL、OAuth蔓延和AI驱动端点带来了新的领地，而旧日可靠的漏洞——BOLA和身份验证缺陷排在最前——依然遍地都是。把这篇文章里的漏洞类别吃透，有章法地测试，你会发现猎物多得很。

参考资料

[1] https://labs.detectify.com/how-to/how-to-hack-apis-in-2026/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《2026年API攻击指南：从基础到前沿漏洞》