去年某招聘平台被曝出数据泄露，信息泄露修复起因不是漏洞数据库被拖，也不是建议接口鉴权被绕过——是Swagger UI页面直接挂在外网，任何人都能打开。信息泄露修复点开一看，漏洞所有API接口、建议参数结构、信息泄露修复请求示例整整齐齐列在那里，漏洞连内部管理接口的建议调试地址都没删。攻击者不需要逆向，信息泄露修复不需要猜路径，漏洞照着文档发请求就行。建议这种事我见过不止一次，信息泄露修复每次排查下来，漏洞问题都出在同一个地方：开发阶段为了方便调试留下的建议配置，上线时没人管。

Swagger（现在更多叫OpenAPI）本身不是漏洞。它是一套接口描述规范，配合springdoc、springfox这类工具，能自动扫描Controller生成文档页面。问题在于，很多项目默认把这个页面暴露在公网，而且没有任何访问控制。`/swagger-ui.html`、`/v2/api-docs`、`/v3/api-docs`、`/swagger-resources`，这几个路径扫一遍，中招的一大片。更麻烦的是，有些团队用Knife4j或自定义UI，路径变了但本质没变，照样能被指纹识别出来。

泄露的内容比很多人想象的严重。接口路径只是最基础的，请求参数名、类型、是否必填、示例值全都有。如果代码里用了`@ApiModelProperty`注解写了注释，那连字段的业务含义都一并暴露。举个例子，一个用户查询接口，参数里有个`roleId`，文档里注释写着“1=普通用户，2=管理员，9=超级管理员”。攻击者拿到这个，直接遍历`roleId`试越权。还有人把内部调用的接口也扫进去了——比如`/internal/syncUserData`、`/admin/cache/refresh`，这些接口可能压根没做鉴权，因为开发觉得“内网才能访问”。

修复这件事，核心思路就一条：生产环境不该让外部看到Swagger文档。具体怎么做，分几种情况。

最直接的办法是彻底关闭。Spring Boot项目里，如果用的是springfox，在`application-prod.yml`里加`springfox.documentation.enabled=false`。springdoc的话，配置`springdoc.api-docs.enabled=false`和`springdoc.swagger-ui.enabled=false`。但注意，很多人只在主配置文件里改了，忘了`bootstrap.yml`或者环境变量覆盖的情况。改完拿curl测一下`/v3/api-docs`，返回404才算数。

如果确实需要保留文档，比如给内部前端团队看，那就加访问控制。Spring Security配一个`HttpSecurity`规则，把`/swagger-ui/**`和`/v3/api-docs/**`限定为内网IP段或者特定角色。别用简单的Basic Auth，那玩意儿在浏览器里弹窗体验差，而且凭证容易泄露。用JWT或者Session都行，关键是别让未认证请求碰到这些路径。Nginx层面也能做，`allow 10.0.0.0/8; deny all;`，简单粗暴但有效。

还有一种情况是网关层统一处理。如果项目走了Spring Cloud Gateway或者Kong，直接在网关路由规则里把Swagger相关路径的对外路由删掉，只保留内网路由。这样后端服务不用改，运维层面一刀切。我见过一个团队用Kong的`pre-function`插件，匹配到`/swagger`路径就返回403，连后端都不转发，性能损耗几乎为零。

生产环境关闭了，开发环境也别大意。很多公司内网办公网和测试环境是通的，测试环境的Swagger页面如果没鉴权，内部人员随手一扫也能拿到接口清单。更别说有些测试环境直接映射了公网端口。建议测试环境也加一层简单的认证，至少别让未登录用户直接看到文档列表。

最后说个容易被忽略的点：Swagger的静态资源文件。有些人把`swagger-ui`的HTML和JS打包进了生产jar，即使关闭了自动配置，这些静态文件还能通过`/webjars/springfox-swagger-ui/...`之类的路径访问到。虽然拿不到接口数据，但能确认你用了Swagger，给攻击者提供了指纹信息。检查一下`META-INF/resources`目录，该删的删掉。

修复完拿工具验证一下。用`curl -I`看响应码，用Burp Suite的主动扫描跑一遍，或者直接拿nuclei的swagger模板扫。别自己觉得改好了就完事，很多时候配置没生效是因为多环境配置文件加载顺序的问题。我习惯改完之后重启服务，再拿一个干净的浏览器无痕窗口访问一遍，确认返回的是登录页或者404，而不是那个熟悉的绿色Swagger UI。

(责任编辑：探索)