swagger api 信息泄露漏洞 原理扫描

某天深夜，信息泄露一个安全测试员对着客户的漏洞目标站点随手敲了个路径。他输入的原理是 /swagger-ui.html，浏览器里居然弹出了完整的扫描API接口文档——登录接口、支付接口、信息泄露后台管理接口，漏洞参数、原理请求方式、扫描返回结构全裸奔。信息泄露他连密码都没猜，漏洞直接照着文档里的原理一个管理接口发了条空请求，服务器回了个200。扫描三分钟后，信息泄露测试报告的漏洞第一行写着：高危，Swagger未授权访问。原理

这类漏洞在真实攻防里太常见了。很多开发团队把Swagger当成开发期的“便利贴”，项目上线时忘了撕掉。便利贴本身没错，错的是把它贴在公司大门口，还贴得整整齐齐，连内网地址、测试账号都写在上面。原理不复杂——Swagger是套API文档工具，它通过一个JSON或YAML配置文件描述所有接口。框架自带UI页面，默认路径就那么几个：/swagger-ui.html、/v2/api-docs、/swagger/index.html。只要没加访问控制，任何人都能拿到这份“接口地图”。

扫描器干的事更粗暴。它就拿着常见路径字典，挨个请求目标域名。状态码200且响应体里有"swagger"或"openapi"字样，就报告漏洞。有些扫描器还会顺手解析接口定义，把没鉴权的接口单独列出来——这就有点狠了，等于把地图上的金矿坐标也标了出来。我见过一个电商站，Swagger文档里躺着个/admin/order/export接口，GET请求直接导出全量订单。开发解释说是给内部运营用的，忘了加token校验。忘了。就这俩字，价值几百万的订单数据差点流出去。

但别急着把所有Swagger暴露都判死刑。有个细节常被忽略：springdoc和springfox生成的文档格式略有差异，老版本Swagger 2.0的api-docs返回的是JSON数组结构，OpenAPI 3.0则是对象嵌套。扫描器如果只认关键词，容易把某些静态资源路径误报成漏洞——比如有些前端项目把swagger的css或js文件也放在根目录，响应体里带个"swagger"字符串就触发告警。我调过几次这种误报，点开一看，是UI资源文件，根本不含接口定义。所以靠谱的验证方法是手动访问/v2/api-docs，看返回的JSON里有没有"paths"字段，那才是接口列表的核心。

修复方案老生常谈，但执行起来总打折扣。最保险的是生产环境直接禁用Swagger依赖，用Maven profile区分环境，开发环境才引入springfox-boot-starter。如果实在要保留，至少加个Spring Security的路径拦截，或者用Nginx对/swagger、/v2开头的URI做IP白名单。有个土办法挺管用——改默认路径，把springfox.documentation.enabled设成false，再通过自定义Docket配置把路径改成一段随机字符串。扫描器字典里没有，攻击者得靠猜。当然，这治标不治本，核心还是别把内部文档当公开资源。

对了，扫描报告里如果出现这个漏洞，别只盯着修复。回头查查访问日志——Swagger路径的请求记录，如果发现来自陌生IP的规律性试探，说明对方不是瞎撞，是照着漏洞库打的。这时候该做的不是改配置，是查横向移动痕迹。漏洞本身是入口，真正危险的是入口背后没关严实的门。文档泄露只是开始，接口能不能被直接调用才是关键。下次上线前，拿扫描器跑一遍自己站点，看到Swagger亮了红灯，先别急着骂开发，想想你家的API文档是不是也躺在某个公开路径上晒太阳。