SwaggerAPI信息泄露漏洞

去年秋天，信息泄露我帮一个做电商的漏洞朋友看他的后台系统。刚打开浏览器，信息泄露顺手在域名后面敲了 /swagger-ui.html。漏洞页面刷出来了——所有接口整整齐齐列在那儿，信息泄露连参数说明、漏洞请求示例、信息泄露返回结构都写得明明白白。漏洞朋友凑过来看了一眼：“这有啥问题？信息泄露方便我们前后端联调啊。”我没说话，漏洞点开一个 /api/v1/user/export 的信息泄露接口，直接请求，漏洞三万条用户手机号和收货地址就下来了。信息泄露他脸白了。漏洞

Swagger 本身是信息泄露个好东西。写 API 文档太痛苦，Swagger 让开发者用注解自动生成接口文档，还能直接测试。问题是，太多人只图方便，忘了关。生产环境里，/swagger-ui.html、/v2/api-docs、/v3/api-docs 这些路径大摇大摆地开着，像把自家户型图和钥匙孔位置贴在大门上。

泄露的东西比很多人想的要命。接口路径只是开胃菜。参数名、数据类型、示例值，这些暴露了后端的数据结构。更狠的是，有些 Swagger 页面里直接嵌了测试用的 token 或者默认账号密码。我见过一个系统，/swagger-resources 下面返回的配置里，赫然写着 “Authorization: Bearer eyJhbGciOi...”，一个长期有效的 JWT。拿着这个 token，你能以管理员身份调所有接口。

为什么这个问题反复出现？跟开发习惯有关。本地开发时 Swagger 开着，方便调试。上线时，打包脚本没改，配置文件没切，Swagger 的依赖还在，注解还在。运维不懂，开发忘了，安全测试没覆盖。三方叠加，漏洞就留在那儿了。我甚至见过一个政府项目，Swagger 页面挂了两年多，直到有人把接口列表发到论坛上才被发现。

怎么查？简单。拿目标域名，拼几个常见路径。除了上面说的，还有 /swagger.json、/openapi.json、/api-docs、/swagger/index.html。有些框架会改路径，比如 Spring Boot 默认是 /v2/api-docs，但有人改成 /api/swagger。用 Burp 或者 ffuf 跑个小字典，几分钟的事。返回 200 且内容里带 “swagger” 或 “openapi” 的，基本就是。

修复也直接。生产环境别开 Swagger。如果非要用，加认证，加 IP 白名单，或者用 Nginx 把 /swagger 路径挡掉。Spring Boot 里设 springfox.documentation.enabled=false，或者用 @Profile 注解限定只在 dev 环境加载。别偷懒。我见过一个团队，用 Nginx 规则把 /swagger-ui.html 返 403，但忘了 /v2/api-docs，结果 JSON 接口照样泄露全部信息。堵一个口子没用，得把所有相关路径都堵上。

这事说到底，不是技术多难，是意识问题。开发者觉得“反正外网访问不到”，运维觉得“这是开发的事”，安全团队觉得“不在扫描范围”。Swagger 泄露的接口信息，往往是攻击者画攻击路径图的起点。一个 /api/v1/admin/deleteUser 接口暴露出来，后面就是找参数、找 token、找逻辑漏洞。链条从这一步开始。

我自己的习惯：拿到一个目标，先看 Swagger。有，就记下来，看看接口权限控制怎么样。没，就换条路。但说实话，十个系统里，至少两三个能直接看到 Swagger 页面。这个比例，几年了没怎么降。