一个晴朗的未授问漏下午，某甲方安全测试群里突然有人甩出一张截图：Swagger UI 页面，权访白底蓝字，洞原接口列表像超市货架一样整齐排列。理扫截图下面附了一句："这站点的未授问漏接口全裸奔了，连登录都省了。权访"

Swagger 这东西，洞原原本是理扫开发者的好帮手——写 API 文档、调试接口、未授问漏生成客户端代码，权访一套流程行云流水。洞原可问题在于，理扫很多团队把 Swagger 部署到生产环境后，未授问漏压根没做访问控制。权访于是洞原，本该是"内部参考手册"的文档，变成了黑客眼中的"靶场地图"。

原理并不复杂。Swagger 的 UI 页面和 JSON 描述文件（通常叫 swagger.json 或 openapi.json）默认允许任何人访问。攻击者只要知道路径，或者用目录扫描工具碰碰运气，就能看到所有接口的定义：参数、返回结构、认证方式，甚至某些接口的调试按钮都明晃晃摆在那儿。更致命的是，部分 Swagger 配置还允许直接"Try it out"——不需要令牌，不用会话，点一下就能调接口。

我印象最深的一次测试，目标是个银行内部系统。Swagger 页面打开后，里面躺着一个"导出用户信息"的接口，参数只要一个日期范围。我试着填了昨天的日期，回车，下载下来一个 200MB 的 CSV 文件，里面是几万名客户的姓名、手机号、身份证号。整个过程不到五分钟。事后查日志，那个 Swagger 端点已经暴露了整整十一个月。

扫描这种漏洞，说白了就三步。第一步，探测路径。常见路径包括 /swagger-ui.html、/swagger/index.html、/v2/api-docs、/v3/api-docs，以及一些自定义的如 /doc.html。第二步，验证响应。如果返回的是 HTML 页面且包含"Swagger UI"字样，或者 JSON 文件里有"openapi"或"swagger"字段，基本就确认了。第三步，测试未授权调用。挑几个接口，看是否需要认证头。如果直接返回业务数据，那就是实锤。

但有意思的是，很多开发人员不认为这是漏洞。他们觉得"Swagger 只是文档，又不改数据"。可实际上，某些接口设计得极其"信任"调用方——比如删除操作只传个 ID，没有额外的权限校验。攻击者通过 Swagger 拿到接口列表后，完全可以遍历 ID，批量删除数据。我见过一个案例，某电商平台的 Swagger 暴露了订单详情接口，攻击者循环调用，把几万条订单信息全扒走了。开发者的回复是："我们以为 Swagger 只在内网用。"——可那台服务器明明有公网 IP。

扫描工具的写法也很直白。用 Python 加 requests 库，几十行代码就能搞定。核心逻辑就是发 GET 请求，判断状态码和内容特征。有经验的测试者会加上并发和超时处理，还会用随机 User-Agent 规避简单的 WAF 规则。但说实话，这种漏洞根本不需要高级技巧，纯属"碰运气 + 路径字典"的活儿。真正的难点在于修复——很多团队连 Swagger 在哪个配置文件里开启的都不清楚。

我见过有的企业用 Nginx 加 IP 白名单，有的给 Swagger 套上登录认证，还有的直接在网关层拦截所有 /swagger 路径。最省事的办法是生产环境彻底禁用 Swagger，只在测试环境开启。可总有开发者嫌麻烦，偷偷改回来。所以每次扫描，我都会顺带检查一下 HTTP 响应头里的 Server 字段——如果发现是 Spring Boot 的默认错误页，那 Swagger 大概率还活着。

说到底，Swagger 未授权访问是典型的"开发便利性"和"安全边界"打架的产物。它不像 SQL 注入那么需要技巧，也不像反序列化那么复杂，但危害程度一点不低。毕竟，知道接口怎么调，和知道钥匙放在哪，本质上是一回事。