内容摘要：Swagger UI 的页面还挂在公网上，攻击者连密码都不用猜，直接访问 /swagger-ui.html 或 /v3/api-docs 就能把你们后端接口的路径、参数、数据结构全部拉下来。我见过一个

Swagger UI 的信息泄露修复页面还挂在公网上，攻击者连密码都不用猜，漏洞直接访问 /swagger-ui.html 或 /v3/api-docs 就能把你们后端接口的建议路径、参数、信息泄露修复数据结构全部拉下来。漏洞我见过一个金融项目，建议Swagger 文档里连内部转账接口的信息泄露修复字段都写得清清楚楚，等于把银行金库的漏洞图纸贴在了大门口。

这类漏洞的建议根源往往不是技术难度，而是信息泄露修复惰性。开发环境里为了方便联调，漏洞随手开启了 Swagger，建议上线时忘了关。信息泄露修复或者更常见——有人觉得“内网没事”，漏洞结果边界设备一配置失误，建议内网就变成了公网。别笑，某知名电商平台就出过这事，Swagger 暴露了订单管理接口，被脚本小子扫到后刷了一晚上优惠券，损失够买几台服务器。

修复方案分几个层次，从懒人到勤快人都有对应招数。

最粗暴也最有效的一招：生产环境直接禁用。在 Spring Boot 的配置文件里，把 springdoc.api-docs.enabled 和 springdoc.swagger-ui.enabled 都设为 false。这招能解决九成问题。但别以为完事了，有人会在测试环境、预发环境也开着 Swagger，这些环境往往和办公网打通，且防护更弱。所以规矩得立清楚：只有本地开发环境允许开启，其他环境一律关掉，用 CI/CD 流水线在构建时强制注入关闭配置。

如果某些团队确实需要在线文档来对接前后端，那就加一层访问控制。别用那种简单的 Basic Auth，密码写在代码里等于没写。用 Spring Security 或者网关统一鉴权，对接你们公司的 SSO。我见过一个团队把 Swagger 挂在 Nginx 后面，配了 IP 白名单，结果管理员出差用手机热点访问不了，一怒之下把白名单删了——后来被脱裤了。所以要做就做完整，别留后门。

还有个容易被忽略的细节：Swagger 的 API 文档里经常包含内部字段，比如 userId、role、甚至数据库表名字段映射。就算你加了登录认证，这些信息对内部员工也不该全量可见。建议用 springdoc 的 @Hidden 注解或者分组配置，只暴露必要的接口。比如用户端 App 需要的接口归一组，管理后台的接口归另一组，管理组只对特定角色开放。

最后说个偏门但实用的技巧。有些人把 Swagger 路径改得比较隐蔽，比如 /api-docs-abc123，以为能避开扫描器。别自欺欺人了，现在攻击者用 favicon 哈希扫描，或者直接遍历常见路径，改路径顶多增加几分钟的扫描时间。真正的安全靠的是纵深防御：禁用、鉴权、最小化暴露，三层都做到，才算松口气。

对了，修复之后记得复查一遍。不是看配置改没改，而是实际用无痕浏览器访问一下，确认页面打不开，接口文档返回 401 或 404。我见过有人改了配置但没重启服务，或者缓存了旧页面，白忙活一场。安全修复这种事，验证永远比操作更重要。