news 2026/9/30 8:21:35

接口安全测试:容易被忽略的 API 高危漏洞盘点

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
接口安全测试:容易被忽略的 API 高危漏洞盘点

接口安全测试:容易被忽略的 API 高危漏洞盘点

前言

现在前后端分离、小程序、APP、H5 业务,几乎所有交互都依靠 API 接口。很多安全测试人员习惯性使用扫描器,重点检测 SQL 注入、XSS 这类传统 Web 漏洞。但 API 场景下,大量高危漏洞属于授权缺陷、业务逻辑缺陷、配置错误,扫描器很难发现,也是很多企业上线前容易漏掉的安全短板。

很多开发认为:接口加了 Token、加了前端 sign 签名,接口就是安全的。但签名只能防参数篡改,不能替代后端权限校验、字段校验、幂等控制。
本文结合 OWASP API Top10,盘点接口安全测试中高频、但容易被忽略的高危 API 漏洞,附带原理、测试方法和修复方案,适合渗透测试、SRC 挖洞、甲方接口安全基线测试。

免责声明:本文技术内容仅用于已获得书面授权的接口安全测试、网络安全学习。严禁在未授权系统中调用、探测接口,任何未经授权的接口测试行为,违反网络安全相关法律法规。

0x01 BOLA 失效的对象级授权(水平越权,API 类第一高危)

漏洞原理

BOLA(Broken Object Level Authorization,原 IDOR 不安全的直接对象引用),也是接口测试最常挖到的高危漏洞。接口接收用户可控 ID(orderId、userId、couponId),后端只校验 Token 是否登录有效,没有校验该用户是否拥有这条数据的操作权限OWASP Deve…。

实战场景

普通用户 A 调用查询订单接口:

GET /api/order/detail?orderId=10001 Authorization: Bearer token_A

正常返回 A 自己的订单。修改 orderId 为其他用户的订单编号10002,携带 A 的 Token 直接请求,成功拿到用户 B 的订单信息、手机号、收货地址。

容易忽略的点:批量查询接口更容易踩坑。POST /api/order/batch,传入{"ids":[10001,10002,10003]},单条接口做了权限校验,但批量接口忘记校验,一次性批量遍历大量用户数据。

测试方法

  1. 准备两个账号 A、B;
  2. A 账号获取自己资源 ID;替换为 B 的资源 ID,使用 A 的 Token 发起请求;
  3. 观察是否返回 B 的敏感数据;
  4. 额外测试批量查询、导出接口,这类接口权限校验最容易遗漏。

修复方案

后端查询数据时,数据库查询语句必须同时带上当前登录用户 ID 作为查询条件,禁止只根据前端传入的资源 ID 查询数据。

0x02 BOPLA 对象属性级授权失效(批量赋值 / 字段越权)

很多测试人员只关注 ID 越权,很容易忽略 BOPLA(Broken Object Property Level Authorization)。简单理解:用户可以正常访问某个对象,但是可以修改对象内不允许操作的敏感字段(大量赋值漏洞)。

实战场景

修改个人信息接口:

PUT /api/user/profile { "email":"test@shturl.", "is_admin":true }

业务本意只允许用户修改邮箱,但是后端直接接收全部 JSON 字段更新数据库。攻击者在请求体新增is_admin:true字段,直接提升为管理员权限。

另一种场景:过度返回数据。查询个人资料接口,返回完整 JSON,包含身份证、银行卡、内部标记字段,前端页面只是不展示,但原始接口响应里面明文返回敏感信息,依靠前端过滤,后端没有做字段过滤。

测试方法

  1. 正常抓包,查看接口返回所有字段;
  2. 在请求体里新增额外敏感字段(is_admin、role、balance),提交请求;
  3. 查看字段是否成功写入数据库;
  4. 检查接口返回 JSON,是否包含前端不需要的敏感字段。

修复方案

后端采用字段白名单,只接收允许修改的字段;返回数据时,后端做字段过滤,不能直接返回数据库实体全部字段。

0x03 BFLA 功能级权限失效(垂直越权)

BOLA 是 “同角色,访问别人的数据”;BFLA(Broken Function Level Authorization)是低权限用户调用管理员专属接口,属于垂直越权。

场景

管理员接口/api/user/list,用于查询全部用户列表。开发只在前端菜单隐藏入口,后端没有做角色校验。普通用户拿到接口路径,携带普通用户 Token 直接请求,成功获取全站用户数据。

容易踩坑:REST 风格接口、旧版本 v1 接口、后台管理 API,前端隐藏之后,很多开发忘记后端鉴权。

测试方法

  1. 使用管理员账号抓取所有后台接口;
  2. 替换 Token 为普通用户 Token,直接调用管理员接口;
  3. 测试 PUT、DELETE 这类高危操作接口。

修复方案

所有接口统一做角色权限校验,不能依靠前端隐藏菜单;基于 RBAC 权限模型,在网关或者接口层统一拦截。

0x04 认证机制缺陷:JWT/Token 安全问题

传统扫描器很少深度检测 Token,这一块漏洞很容易漏掉。
常见缺陷:

  1. JWT 签名未校验:后端直接信任 JWT 载荷,不校验签名。攻击者修改 payload 里面userId,重新生成 JWT,直接接管其他用户账号;
  2. Token 永久有效,没有过期时间;
  3. 刷新 Token 没有绑定设备,泄露之后可以无限续期;
  4. Token 放在 URL 参数传递,日志里会记录 Token,造成泄露。

坑点:很多开发认为 JWT 自带安全,只要生成就没问题,忽略签名校验、过期时间、密钥泄露风险。

测试方法

  1. 拿到 JWT,修改 payload 中的用户 id,重新编码,发送请求;
  2. 删除 exp 过期字段,测试是否仍然有效;
  3. 查看 token 是否在 URL 中传输。

修复方案

后端必须校验 JWT 签名;设置合理过期时间;密钥严格保管,不能硬编码;Token 放在请求头 Authorization,禁止放在 URL。

0x05 接口缺少幂等控制,业务重放漏洞

这是业务类 API 高频漏洞,扫描器完全无法发现。同一个请求多次重放,产生多次业务效果。

典型场景:

  1. 领取优惠券接口,没有幂等,多次重放,无限领取优惠券;
  2. 订单提交接口,重复创建订单;
  3. 核销接口,同一个核销码重复提交,多次核销。

很多业务仅前端限制按钮,后端没有防重放机制。

测试方法

Burp 抓取业务提交请求,使用 Repeater 多次重复发包,观察业务是否多次生效。

修复方案

业务接口增加幂等号(unique 流水号),后端数据库唯一索引;同一个流水号只处理一次。

0x06 未限制资源消耗(无频率限制)

API4:Unrestricted Resource Consumption,缺少限流、配额限制。
风险场景:

  1. 登录、找回密码接口无频率限制,暴力破解、撞库;
  2. 短信验证码接口无限制,短信轰炸;
  3. 大数据查询接口,不限制分页大小,传入超大 pageSize,一次性拉取全库数据,造成数据库拖库、服务 DoS。

容易忽略:内部接口、后台接口,开发默认只有内网访问,不添加限流。一旦内网被突破,直接拖库。

测试方法

  1. 对登录、短信接口进行多次循环请求;
  2. 修改分页参数 pageSize=99999,观察接口返回数据量。

修复方案

按用户 / IP 维度增加接口限流;分页参数后端强制上限,拒绝超大分页。

0x07 影子 API、遗留旧接口(资产管理不当)

OWASP API9 不当资产管理,这个漏洞经常被忽略。
很多项目迭代过程中,旧版本 API/api/v1/xxx已经下线、前端不再使用,但是后端服务没有删除。旧接口安全校验薄弱,存在大量漏洞,形成影子 API,没有纳入安全管理、扫描、基线检查范围。

还有:预发布环境 API 直接暴露在公网,测试 swagger 文档开放公网访问,泄露全部接口参数。

测试方法

  1. 收集接口版本,v1/v2/v3,测试废弃旧版本接口;
  2. 探测/swagger、/openapi.json,查看接口文档是否公网可访问。

修复方案

梳理全量 API 资产,下线废弃旧接口;生产环境禁用 Swagger、OpenAPI 文档。

0x08 SSRF 服务端请求伪造(API 参数传入 URL 场景)

很多 API 支持传入 URL,用于图片抓取、网页预览、文件下载、webhook 回调。如果没有严格校验 URL 目标,会触发 SSRF。

攻击者传入内网地址http://127.0.0.1:8080,让服务器访问内网,探测内网资产、读取内网服务数据。

容易忽略:webhook 回调接口、图片远程上传接口,这类接口开发很少做内网地址过滤。

测试方法

传入可控 URL 参数,使用 Burp 的 SSRF 探测 payload,尝试访问本地回环地址、内网网段。

修复方案

URL 白名单校验,禁止访问内网、回环地址;使用独立网络环境,服务器禁止访问内网。

0x09 CORS 跨域配置错误

很多接口 CORS 配置不当,Access-Control-Allow-Origin: *,或者动态直接读取 Origin 头,未做校验,允许任意域名跨域读取接口返回敏感数据。
搭配 Cookie 认证场景,会造成跨域窃取用户数据。

测试方法

修改请求 Origin 头为任意恶意域名,查看响应头Access-Control-Allow-Origin是否返回该域名。

修复方案

CORS 配置使用可信域名白名单,不要直接配置*;高敏感接口不要允许跨域。

0x10 注入类漏洞(JSON 注入、NoSQL 注入)

传统 SQL 注入大家都熟悉,但是 JSON 格式接口容易忽略 NoSQL 注入、参数注入。
比如 MongoDB 接口,传入{"username":{"$ne":null}},绕过登录查询,直接查询全部用户。
还有参数污染、JSON 参数类型混淆(数字和字符串切换)。

测试方法

在 JSON 请求体中插入 NoSQL 操作符,观察接口返回数据。

修复方案

参数强类型校验,使用参数化查询,禁止直接拼接用户输入到查询语句。

0x11 签名机制缺陷(很多开发误以为签名万能)

前面 JS 逆向文章提到的接口 sign 签名,这里讲签名本身的漏洞:

  1. 签名只对部分参数做计算,攻击者修改未参与签名的参数;
  2. 密钥硬编码在前端 JS;
  3. 没有 nonce 一次性随机串,仅靠 timestamp,时间窗口内可以重放;
  4. 签名算法弱,MD5 无加盐。

重点:前端签名只是防普通爬虫,不能作为权限校验依据,不能阻止越权、业务漏洞。很多企业踩坑,以为加了 sign 接口就安全,忽略后端校验。

0x12 接口安全标准化测试流程(实战可用)

  1. 资产梳理:收集全部 API,包含版本、废弃旧接口、swagger 文档;
  2. 认证测试:Token/JWT 校验、过期、传输方式;
  3. 权限测试:BOLA、BFLA、BOPLA(多账号对照测试);
  4. 业务测试:幂等、重复提交、参数篡改;
  5. 资源限制:限流、分页、请求大小;
  6. 注入与特殊接口:SSRF、NoSQL 注入、CORS;
  7. 信息泄露:响应返回敏感字段、详细报错堆栈;
  8. 影子接口排查,扫描遗留旧版本 API。

0x13 高频踩坑总结

❌坑 1:扫描器没有告警,就认为接口没有漏洞

大部分权限类、业务逻辑类 API 漏洞,自动化扫描器无法识别,必须人工多账号测试。

❌坑 2:接口加了 sign 签名,就跳过权限测试

sign 仅校验参数完整性,不能校验用户资源归属,依然存在 BOLA 越权漏洞。

❌坑 3:只测试前端调用的接口,忽略 v1 旧版本、后台内部接口

影子 API 往往是攻击突破口,安全测试必须覆盖全部接口资产。

❌坑 4:只做对象级别权限,忽略字段级权限(BOPLA)

允许用户提交额外字段,造成批量赋值提权,这类漏洞隐蔽性极强。

❌坑 5:依赖前端按钮禁用,后端不做幂等和次数限制

前端限制很容易通过抓包绕过,后端校验才有效。

0x14 企业 API 安全建设建议

  1. API 网关统一管控鉴权、限流、日志,不要分散在各个业务代码;
  2. 上线前做接口安全评审,重点审核权限逻辑;
  3. 维护 API 资产清单,及时下线废弃旧接口;
  4. 采用 Schema 校验,对入参做严格校验,使用字段白名单;
  5. 敏感业务接口增加幂等、防重放;
  6. 定期人工渗透测试,不能只依靠自动化扫描。

总结

API 安全的核心风险和传统 Web 差异很大,权限失效类漏洞是 API 场景最高危的风险。很多接口漏洞不会出现报错、注入特征,只是返回了不属于当前用户的数据,或者执行了不允许的业务操作。

接口安全测试,不能依赖扫描器一键扫漏洞,需要站在业务角度,多账号、多角色对照测试,关注权限、字段、业务状态、幂等性。
前端签名、Token 认证、加密传输,都只是安全防护中的一环,后端多层次的权限校验、参数校验,才是 API 安全的根基。

一句话记住:扫描器只能发现特征漏洞;API 高危漏洞大多藏在权限和业务逻辑里,需要人工对照多账号测试。


最后

关于网络安全技术储备

学好网络安全不论是就业还是做副业赚钱都不错,但要学会网络安全还是要有一个学习规划。最后大家分享一份全套的网络安全学习资料,给那些想学习网络安全的小伙伴们一点帮助!

对于0基础小白入门:

如果你是零基础小白,想快速入门网络安全是可以考虑的。

一方面是学习时间相对较短,学习内容更全面更集中。

二方面是可以找到适合自己的学习方案

包括:网安成长学习路线图、SRC&黑客文档、护网行动、黑客必读书单、面试题、学习视频等教程。带你从零基础系统性的学好网络安全!

需要的可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

👉1.成长路线图&学习规划👈
要学习一门新的技术,作为新手一定要先学习成长路线图,方向不对,努力白费。

对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。

👉2.网安入门到进阶视频教程👈
很多朋友都不喜欢晦涩的文字,我也为大家准备了视频教程,其中一共有21个章节,每个章节都是当前板块的精华浓缩。(全套教程文末领取哈)

👉3.SRC&黑客文档👈
大家最喜欢也是最关心的SRC技术文籍&黑客技术也有收录

SRC技术文籍:

黑客资料由于是敏感资源,这里不能直接展示哦!(全套教程文末领取哈)

👉4.护网行动资料👈
其中关于HW护网行动,也准备了对应的资料,这些内容可相当于比赛的金手指!

👉5.黑客必读书单👈

随着互联网技术的飞速发展,网络安全已经成为了当今科技领域的一大热点。这些SQL注入、CCNA、Web渗透、Linux服务器等,以其强大的语言理解和防御能力,正在守护着我们网络世界。 那以下这些PDF籍就是非常不错的学习资源。

👉6.网络安全岗面试题合集👈
当你自学到这里,你就要开始思考找工作的事情了,而工作绕不开的就是真题和面试题。

这份完整版的网络安全学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/30 8:21:34

深度学习性能优化:数据缓存、显存分配与KV Cache实战指南

简介:一份面向Armv8/Armv9底层开发者的《深度学习cache系列》PDF文档,系统讲解高速缓存工作原理与实际工程应用。内容从“为什么要用cache”切入,依次介绍L1/L2/L3多级缓存结构、索引/路/集合的组织形式,以及VIVT、PIPT、VIPT等缓…

作者头像 李华
网站建设 2026/9/30 8:21:34

HER算法解析:用后见之明破解稀疏奖励难题

第一次看到 hindsight 这个词,是在 OpenAI 那篇著名的论文里。当时我在调一个机械臂推球任务,奖励信号稀薄到让人绝望——智能体在几千个回合里几乎吃不到一次正反馈,训练曲线就跟心电图一样在零附近抖动。那篇论文的名字叫 Hindsight Experi…

作者头像 李华
网站建设 2026/9/30 8:21:26

大厂开发岗35岁危机真相:年龄从来不是问题,不可替代性才是

有人问“大厂开发岗35岁危机是不是很严重”,我的回答是:真话可能不中听干了十几年开发,从外包干到中大厂,再从大厂跳到小厂做技术负责人,中间被裁过、也裁过人。这几年总有人私信问我:"大厂开发岗是不…

作者头像 李华
网站建设 2026/9/30 8:21:24

IPD咨询洞察:华为项目管理GRPI四步法:把一盘散沙拧成高绩效团队

好团队什么样?在华为眼里,它得有共同目标、能分工协作、可技能互补、彼此负责、还守同一套规则。可现实里,你大概率遇到过这样的团队:目标会上都说懂,一散会各干各的;活儿来了互相推,出了事互相…

作者头像 李华
网站建设 2026/9/30 8:21:12

Semaphore限流原理:AQS与CAS如何协同实现并发控制

面试官一句“你讲讲 Semaphore 的限流原理,扯上 AQS 和 CAS 的那种”,能当场卡住不少人。背过八股的人都会说“Semaphore 是信号量,基于 AQS 实现”,但真被追问到“AQS 怎么配合 CAS 把线程拦住”“非公平模式下凭什么性能更高”“…

作者头像 李华