前言
本文将叙述当前的API安全相关问题，在当前的Web形式中，转向微服务架构似乎是大势所趋，架构的更迭从以往的单体架构，像 PHP、JSP 时代，身份验证、数据库查询、HTML 渲染都在一个进程里完成。现在的标准是"前后端分离 + 微服务"。前端（Vue/React）只负责展示，所有的业务逻辑全部下沉到了 API。这种解耦的架构下，逻辑漏洞成了大问题，它们不能被自动化测试有效识别，往往是深入在上下文严密的业务过程，所以在当前形势下，API安全越发重要而验严重。
本文会借助portswigger的几个API测试Lab描述几个经典的API问题，并且自2年之前被汇总后，到如今这些逻辑漏洞仍然非常有威胁。
API安全问题所在
API的安全问题集中在业务上下文的逻辑中，所以它有时候很难被自动化工具测试到，甚至说当前的大部分测试工具是无法测试到这些问题的，在当前AI Agent加持下先进的测试厂商试图在测试过程中加入AI，试图理解当前测试过程的上下文，但是当前确实效果一般，再加上API已经完全拥抱了Web，所以显得问题愈发严重。
再者，现在的流行Web架构，前后端完全分离+微服务在后端各种转发，对于没那么成熟的项目来说，有时候确实无法做到一体化的认证和授权，往往仅靠中间件在前面撑着，这样就造成了在后端的整个环境中，完全是处于一种零认证的关系，大有一副：只要数据格式不会错，那么就说明对方是有权限的一种态度，也就造成如当前IDOR、批量赋值、SSPP等等问题，这显现了当业务逻辑下落到最下层的控制器时，它往往是完全信任这个请求的，这也就促成了当前OWAPS的Top1 访问控制失效的一大前提了，只把认证和授权当作动作而非整个架构的组成部分。
Lab 1: Exploiting server-side parameter pollution in a REST URL
这个Lab是通过SSPP和路径遍历在后端翻江倒海找到管理员账户的重置密码的令牌，最终删除用户达成目标。
首先这个在这个Lab中，我们对URL的实际输入会被直接拼接到后端的REST API路径上去，也就是说我们会通过各种尝试、拼接、绕过的方式来访问一些不被允许的内容，最后达成目的，这也是API安全的一类特点吧，前端往往不会对我们的URL输入存在限制，而我们可以想法绕过它，让我的实际输入影响到后端的解析中，路径穿越在此处就非常容易实现，因为我们的URL不是被转发的，而是直接被拼接的，这样的情况下路径穿越往往就不会被限制，因为前端不做解析，它只是将字段拼接到后端的路由上，而这个路由天生就有对路径的逻辑也就是.../(返回上一级)。
执行过程： 进入环境之后，来到账户页面，尝试登录，由于此Lab没有给默认账户，这一步就不会成功，我们的关注点还是放到找回密码上，把流量抓到Burp的重放器中，尝试一些用户：
在此我们确定了administrator作为一个合法账号被允许找回密码，因为加入一个administratorx不被允许访问，再一个就是我们可以试一下./administrator，在尝试一下它是否允许路径穿越，显然它可以./是指当前目录中，既然没有报错也就说明了路径逻辑被正常的处理了
这里尝试一下是否可以凭借路由一步一步到根目录中找到类似于openapi的文档，这里偶然获得了路由错误信息，上面提示了这是一个多个版本的User API且当前是version3.0，并且给出了一条关键点路由信息：/internal/v1/users/{username}/field/{field}
我们这里即刻尝试访问，根据这个错误信息又得到了，当前这个参数值只允许email，我们继续尝试
验证了这个路由信息为email允许访问。
这里有根据在找回密码网页端端静态JS文件中，泄漏了一个passwordResetToken参数，我们产生结合构建一下
提示当前API的版本不允许这个字段访问，这里只允许email，那么结合之前的泄漏的v1路径，我们构建载荷：
javascript
username=../../v1/users/administrator/field/passwordResetToken%23
得到最终的重置令牌，这里只要记录信息，在前端JS泄漏的那个参数中填入得到的令牌，就可以重置administrator的密码，重新登录即可完成目标。
这里完整描述了，后端实际的控制器零认证的过程，只要可以访问就允许访问，在一个就是API测试的过程，可以发现它就是不断的去测试，对于其中任何一个字段都可以进行模糊测试（目标允许的话），这个Lab泄漏了非常多的信息，导致整个过程显得很顺利，但是实际有时候很多字段就是要靠猜，靠模糊测试，这也呼应了为什么零认证，就是认为后端控制器的路由被完美隐藏到后端后，不认为前端可以访问到不该访问的；其次还有就是根本原因了，为什么拼接的URL可以在后端翻江倒海呢，就是前端认为安全的参数被后端理解为了具有逻辑意义且没有被转义最终被执行了，像.../的路径穿越还是#23(#，注释后续内容)，使用URL编码顺利逃过前端的制裁，并且在后端可以直接产生逻辑意义，这也是当前访问控制失效的一个根本原因了，信任了不该信任的参数，且不做任何过滤导致的问题。
Lab 2: Exploiting server-side parameter pollution in a query string
此Lab与上述的攻击逻辑完全一致，但是他们又本质区别，首先这个Lab是通过URL参数解析后给到后续的API，也就是路径穿越会完全失效，它不是简单URL拼接，但是即便如此，逻辑意义仍然完全一致，通过不断的试探URL，使用%23（#）不断试探参数，根据返回的路由信息和错误信息，同时对于一些字段必要时进行模糊测试，使用一些类似于"Server-side variable names"字典进行爆破，同时关注前端的静态JS中泄漏的信息，最终获得管理员重置密码的令牌。
从这两个Lab可以看到，API的测试往往伴随着猜，结合上下文、错误信息去尝试。
Lab 3: Exploiting a mass assignment vulnerability
这个Lab是批量赋值，可以通过添加字段，修改字段值的方式，让目标的逻辑业务出现问题，从而达成目标。这些情况往往出现在服务端对业务数据结构体控制不强，导致前端可以通过模糊测试或者泄漏的信息推导出，结构体中存在的其他字段，而控制器若直接将这些字段序列化，没有看到它的权限流向，就会发生批量赋值，让前端强制将可控的数据注入到后端的数据结构体中。
执行过程： 进入Lab，登录账户，在首页随便添加一个商品，点击购物车，在结算页面进行抓包：
首先会通过GET的方式请求 /api/checkout，这是用于获取当前账户的购物车中的内容，对比前端中显示的信息，可以看到名字、ID、价格等等，让我点击结账，因为信用不够是无法结算的，但是在流量中我们可以发现，结账的请求是POST方式请求/api/checkout
而且JSON字段与GET方式获取购物车内容的字段很相似，我们试着在其中加入商品价格也就是item_price，将其修改为0，尝试结账，发现仍然无法结账，那么就再去尝试JSON的另外一个标签chosen_discount，也就是商品折扣，我们将其调整为100，尝试结账，发现成功。
在这个Lab中，同一个api可以被GET和POST同时完成，且它们的逻辑意义相近但不完全相同，我们就可以试着去补全信息，看看两个请求是否可以返回更多信息，或者更多细节。当然这就是典型的数据层不隔离导致的问题，也还是那句话，服务端为做认证或者认证没有做全，并且过分信任了前端的参数，将其返回的内容直接与内部的数据混在一起来，直接进行了逻辑运算导致的后果。当然，从这里可以映射其他方面，比如这里是折扣，那么如果是类似于is_admin:False，那么甚至可以直接实现越权。
总结
现代API安全的核心矛盾在于：开发者信任了不该信任的输入，而攻击者利用这种信任篡改了原本不应该暴露的业务逻辑。
无论是SSPP、批量赋值还是路径遍历，本质都是输入未经验证地被用于构建内部请求、对象绑定或资源定位。这种信任被滥用后，技术层面的参数污染就演变为业务层面的权限绕过、数据泄露和流程破坏。
2026年的Web已全面转向微服务架构，API数量呈指数级增长，而自动化安全工具的滞后性让逻辑漏洞成为最危险的攻击向量。正如OWASP所指出的：安全不能再是被动的"检测和响应"，而必须是嵌入设计阶段的"左移"实践。