用Burp Suite扫一个刚上线的检测业务系统，Proxy历史里蹦出个/v2/api-docs，到目点使档漏洞处返回200，标站JSON体里整整齐齐列着所有Controller、检测方法名、到目点使档漏洞处参数类型、标站甚至示例值。检测这不是到目点使档漏洞处彩蛋，是标站事故。

Swagger UI本身不是检测漏洞。它是到目点使档漏洞处个调试工具，开发阶段开着挺方便，标站前端联调不用追着后端要接口文档。检测问题出在部署时忘了关。到目点使档漏洞处很多团队用Spring Boot集成springfox或springdoc，标站默认配置下/swagger-ui.html和/v2/api-docs直接暴露在公网，没有任何鉴权。攻击者不需要爆破，不需要猜路径，访问一下就能拿到整套API地图。

我见过最离谱的一个案例。某电商后台系统，Swagger页面没做任何限制，接口列表里赫然躺着/admin/user/delete、/admin/order/refund这类高危操作。更致命的是，这些接口的鉴权逻辑有缺陷——只在前端路由做了权限校验，后端接口本身没验token。攻击者照着Swagger文档构造请求，直接批量删用户、改订单金额。从发现到利用，前后不到十分钟。

为什么Swagger暴露比想象中严重

普通的信息泄露可能只是泄露个版本号、内网IP。Swagger泄露的是完整的接口契约。参数名、参数位置、数据类型、是否必填，全给你标好了。这相当于把靶子的环数都画出来了。攻击者不用再fuzz参数，不用猜接口路径，直接按文档构造payload就行。

另一个容易被忽略的点：Swagger文档里经常包含内部接口。比如/internal/syncData、/debug/executeSql这种本不该对外网暴露的路径。开发觉得反正外网访问不到，文档里留着无所谓。结果Swagger一泄露，这些隐藏接口全成了攻击入口。

还有个现实问题：很多老项目用的是springfox 2.x，/v2/api-docs这个路径几乎成了指纹。Shodan、Fofa上搜一下，全球暴露的Swagger文档数量大得惊人。自动化扫描工具会把这类站点标记出来，后续就是批量漏洞利用。

实际处理时踩过的坑

最直接的办法是在网关层封掉/swagger-ui.html、/v2/api-docs、/swagger-resources、/webjars/这些路径。Nginx加个location规则返回403就行。但要注意，有些项目把context-path改了，路径变成/api/v2/api-docs，规则得跟着调整。

如果用的是Spring Security，可以在配置里直接拦截：

http.authorizeRequests() .antMatchers("/swagger-ui.html", "/v2/api-docs", "/swagger-resources/**").denyAll() .anyRequest().authenticated();

但别高兴太早。有些团队为了省事，Swagger只在内网环境启用，通过@Profile("dev")控制。结果生产环境的profile配错了，或者CI/CD流水线把dev配置带上了线。这种情况光靠网关封路径不够，得从构建流程上卡住——生产打包时强制排除swagger依赖，或者用Maven profile做条件编译。

还有一种情况：Swagger关了，但/actuator端点开着。/actuator/mappings同样能拿到所有接口路径。这属于按下葫芦浮起瓢。处理Swagger暴露时，顺手把actuator的敏感端点也检查一遍，env、beans、heapdump这些该关就关。

验证是否真的修好了

改完配置别急着收工。用curl直接请求/v2/api-docs，确认返回403或404。再用Burp的Repeater换个Host头、加个X-Forwarded-For试试，有些网关规则只认内网IP，伪造头部就能绕过。最后用之前泄露的接口路径实际调一下，确认后端鉴权逻辑真的生效了——别只封了文档路径，接口本身还是裸奔。

Swagger暴露这事，技术难度不高，但暴露面广。每次做渗透测试，只要看到Swagger页面能打开，基本就等于拿到了半张入场券。开发觉得“不就一个文档页面嘛”，攻击者眼里这是完整的攻击路线图。