sourcemap 文件泄露漏洞

2019年，露漏某电商平台的露漏前端工程师在打包时忘了关掉sourcemap生成选项。上线三天后，露漏有人在GitHub上贴出了完整的露漏源码目录树——包括API密钥、内部接口路径，露漏甚至数据库连接串的露漏加密方式。攻击者没费什么劲就摸清了后台的露漏鉴权逻辑。这件事后来在圈内传得很广，露漏但类似的露漏低级错误，今天依然每天都在发生。露漏

sourcemap 是露漏什么？简单说，它就是露漏一份“翻译表”。现代前端代码经过 Webpack、露漏Vite 这类工具压缩、露漏混淆之后，露漏变量名变成 a、b、c，函数被塞进一行几千字符的怪物里。浏览器报错时只能告诉你“第1行第23456列出错了”，开发者根本没法调试。sourcemap 就是用来把压缩后的代码映射回原始源文件的。它本身是个好东西，问题出在——很多人把它一起打包上线了。

你打开浏览器的开发者工具，切到 Sources 面板，如果看到 webpack:// 开头的目录结构，里面整整齐齐躺着 .vue、.ts、.jsx 源文件，恭喜，这个站点正在裸奔。更直接的办法是看构建产物：每个 .js 文件末尾通常会有一行 //# sourceMappingURL=app.js.map。把 .map 文件下下来，用 source-map 库解析一下，原始代码就还原了。

泄露的内容取决于项目本身。前端源码里有什么？接口地址、请求参数格式、加密盐值、硬编码的 token、内部系统的域名、注释里写的“TODO: 上线前删掉测试账号”。我见过一个后台管理系统，sourcemap 还原后连数据库表结构和字段注释都看得一清二楚——因为开发者把一份 schema.sql 不小心 import 进了某个工具函数。攻击者拿到这些信息，渗透测试的难度直接降为零。

有人觉得“前端代码本来就是公开的，泄露了也无所谓”。这话对了一半。压缩混淆后的代码和原始源码是两回事。前者像一本撕掉目录和页码的书，后者是带完整索引和批注的手稿。安全边界不在于“代码是否可见”，而在于“可见的代码暴露了多少攻击面”。一个硬编码在源码里的内部 API 网关地址，在混淆代码里可能被拆成字符串拼接，在 sourcemap 里就是一行明明白白的常量。

怎么防？最直接的做法：生产环境构建时关掉 sourcemap。Webpack 设 devtool: false，Vite 设 build.sourcemap: false。如果确实需要线上调试，可以把 .map 文件上传到 Sentry 这类错误监控平台，不随构建产物发布。Nginx 层面也可以拦一道：对 *.map 的请求返回 404。但别只靠 Nginx——有人会把 .map 文件改名混在静态资源里，或者通过 CDN 的边缘节点绕过规则。根本办法还是在构建阶段就不生成。

还有个容易忽略的点：sourcemap 泄露不只发生在 .js 文件。CSS 的 sourcemap、甚至某些框架的调试模式（比如 Vue CLI 的 productionSourceMap 默认是 true），都会把 .vue 单文件组件的源码暴露出来。检查的时候别只看 JS。

我自己的习惯是，每次部署前跑一遍 find dist -name "*.map"，有输出就停下来。这个动作花不了十秒钟，但能挡掉一类完全不该发生的安全事故。前端工程化让构建流程越来越复杂，复杂意味着容易漏。sourcemap 就是那种“默认开启、没人注意、后果严重”的典型。