webpack源码泄露漏洞：一个被忽视的码泄前端安全隐患

某天下午，我在测试一个电商网站时，露漏随手在URL后面加了`/webpack.config.js`。码泄浏览器居然返回了完整的露漏配置文件——数据库地址、API密钥、码泄构建脚本，露漏全部赤裸裸地躺在那里。码泄这不是露漏个例，而是码泄大量前端项目的通病。

Webpack是露漏当前最流行的前端打包工具，几乎每个现代网站都在用它。码泄它把JavaScript、露漏CSS、码泄图片打包成静态资源，露漏但问题出在开发者的码泄配置习惯上。默认情况下，webpack会把`source-map`文件生成到`/dist`目录，这个`.map`文件包含了原始源代码的完整映射。任何人访问`/js/app.bundle.js.map`，就能用浏览器DevTools还原出你的React、Vue或Angular源码。

更糟的是，很多开发者把`webpack.config.js`留在项目根目录，没有做访问控制。这个文件通常包含`entry`、`output`、`plugins`配置，有时候还有`devServer.proxy`指向内部服务，甚至`process.env`注入的敏感变量。我见过一个金融类应用，它的配置文件里硬编码了支付网关的签名密钥。

攻击者利用这类泄露可以做很多事情。最直接的是审计源码找漏洞，比如硬编码的API端点、不安全的加密逻辑、隐藏的后门接口。有次我通过一个`.map`文件发现某个管理后台的登录接口没有做频率限制，配合源码里泄露的默认账号，轻松拿下了测试权限。

另一个常见入口是`/webpack-dev-server`。开发模式下，这个服务默认监听所有网卡，端口通常为8080或3000，且没有任何认证。如果生产环境不小心用`webpack serve`启动了应用，外部访问者就能直接看到源码文件列表，甚至通过`sockjs-node`的WebSocket通道执行热更新指令。

修复方案其实不复杂。第一，生产构建务必设置`devtool: false`或`devtool: 'hidden-source-map'`，后者只生成供错误监控使用的map文件，不暴露给用户。第二，用nginx或云WAF拦截对`*.map`、`webpack.config.js`、`node_modules`的访问请求。第三，别把`.env`文件打进bundle，用`DefinePlugin`注入变量时，只暴露必要的前端环境变量。

我见过最离谱的案例是某国内大厂的营销活动页，它的`main.js.map`文件有23MB，包含了整个项目的业务代码。攻击者直接复制代码改了逻辑，仿冒出一个一模一样的活动页面，用来钓鱼收集用户手机号。事后排查，发现是前端负责人为了调试方便，把`productionSourceMap`设成了`true`，上线后忘了关。

这类漏洞之所以普遍，根源在于前端工程化教育里很少强调生产环境安全。大多数教程只教你怎么跑起来，不教你怎么藏起来。代码打包后，开发者觉得“反正用户看不到源码”，但webpack的source-map机制恰恰打破了这种幻想。你在浏览器里按F12，切到Sources面板，就能看到原始的目录结构和文件内容，这相当于把项目源码直接交给了访客。

最后提一句，如果你要检查自己的站点有没有这个问题，打开控制台看Network，过滤`.js`请求，找`.map`后缀的文件。如果有，直接访问那个地址，能下载到源码就说明中招了。修复后重新构建并清理CDN缓存，别让旧文件继续躺在边缘节点上。