内容摘要：凌晨两点，某安全群里有人甩出一张截图——某大厂内部系统的Swagger UI页面赫然在目，接口列表像超市货架一样整齐陈列。发图的人只配了一句话：“这家的注册接口连验证码都没做。” Swagger这东西

凌晨两点，信息泄露某安全群里有人甩出一张截图——某大厂内部系统的漏洞Swagger UI页面赫然在目，接口列表像超市货架一样整齐陈列。信息泄露发图的漏洞人只配了一句话：“这家的注册接口连验证码都没做。”

Swagger这东西，信息泄露本该是漏洞开发者的拐杖。它把接口文档、信息泄露参数定义、漏洞调试功能打包成一套可视化界面，信息泄露后端写完代码，漏洞前端照着文档就能联调。信息泄露问题在于，漏洞很多团队把它当成了公共厕所——用完不关门。信息泄露默认路径/swagger-ui.html、漏洞/v2/api-docs，信息泄露网上随便一搜就是一堆暴露的实例。我见过最离谱的案例，某金融公司把Swagger挂在生产环境公网IP上，连个Basic认证都没加，点开就能看到“转账”“查余额”“改密码”的接口定义。这哪是文档，这是给黑客递刀。

有人可能觉得，接口文档泄露无非是些字段名和URL，能有多大危害？这么想就天真了。Swagger里藏着的不只是参数，还有开发者的思维习惯——哪些接口没做鉴权，哪些参数直接拼接进SQL，哪些逻辑漏洞在注释里写得明明白白。去年某车企的API泄露事件，攻击者就是从Swagger里发现了一个隐藏的“车辆解锁”接口，配合另一个未授权接口，直接远程开了别人的车门。整个过程没碰任何漏洞扫描器，全靠文档导航。

更麻烦的是，Swagger泄露往往不是孤立问题。它通常意味着整个研发流程的松懈——既然生产环境都不关Swagger，那测试环境是不是也有？日志里是不是打印了token？代码仓库的权限是不是也形同虚设？我见过一个团队，Swagger暴露后顺着排查，发现他们连数据库密码都存在GitHub私有仓库里，而仓库权限是全员可写。这就像家里大门没锁，贼进来后发现卧室门也开着，保险柜干脆没设密码。

修复这件事，技术上一点不难。生产环境关掉Swagger，或者加个严格的IP白名单，再不行就套一层OAuth。但难的是改变态度。很多开发觉得“Swagger开着方便调试”，结果方便了自己也方便了别人。有个做安全测试的朋友跟我说过一句糙理不糙的话：“Swagger不关，等于把自家客厅的监控摄像头接到公网，还顺便告诉小偷哪个窗户没锁。”

说到底，Swagger泄露不是技术漏洞，是管理漏洞。它像一面镜子，照出团队对安全的真实态度——文档可以公开，但接口不该裸奔。你永远不知道哪个闲着没事的黑客，正在用你的Swagger页面练习接口调用。等到某天银行账户少了钱，或者智能家居被人控制，再去翻日志找原因，那时候的Swagger页面，可能已经变成黑客留给你的嘲笑留言板了。