Webpack 5 的升级并不局限在 tree shaking 或持久化缓存上，它在安全边界上的调整同样值得单独拿出来分析。前端构建阶段如果默认注入大量 Node.js 核心模块 polyfill，或者在全局暴露固定名称的加载函数，都有可能为恶意脚本提供可乘之机。Webpack 5 正是从这些细节入手，收窄攻击面，并提供与现代浏览器安全机制更紧密的配合。
移除 Node 核心模块自动 polyfill，减少全局暴露风险
Webpack 4 时代，当代码中引用 crypto、stream、buffer 等 Node.js 核心模块时，打包器会自动注入对应的浏览器 polyfill，保证代码在浏览器里能继续运行。这个行为虽然提升了兼容性，但也把大量 Node 环境专属的全局对象带进了浏览器。比如 process、Buffer、global 这些对象会默认出现在打包产物中，不仅增加了体积，也扩大了全局命名空间的暴露面积。攻击者可以利用这些全局对象进行环境指纹识别，或者在某些场景下结合原型链污染构造更复杂的攻击。
Webpack 5 默认不再自动引入这些 polyfill。如果你在项目里直接使用 crypto 但没有安装对应浏览器实现，构建时会直接抛出模块解析错误。这看起来像是一个破坏性变更，但从安全角度看，它把选择权交还给了开发者。只有明确声明需要某个 polyfill，才会被加入产物。显式配置的方式如下：
module.exports = {
resolve: {
fallback: {
crypto: require.resolve('crypto-browserify'),
stream: require.resolve('stream-browserify'),
process: require.resolve('process/browser'),
},
},
};
通过 resolve.fallback 显式指定浏览器实现，可以让依赖仍然正常工作，同时避免大量无关的 Node 全局对象被隐式注入。升级旧项目时如果遇到类似的模块解析错误，应当优先评估这个 polyfill 是否真有必要，而不是无脑把 v4 的自动行为恢复回来。每个被引入的全局对象，都是一块潜在的攻击面。
Trusted Types 运行时支持，强化 DOM 脚本可信通道
Trusted Types 是浏览器提供的一套安全 API，用来降低基于 DOM 的 XSS 风险。它的核心思路是：所有赋值给 innerHTML、script 元素的文本，必须通过可信策略创建，否则浏览器会直接拒绝执行。很多前端应用在打包后由运行时动态创建 script 标签来加载异步 chunk，如果这些创建过程没有经过 Trusted Types 策略，严格 CSP 环境下会直接报错。
Webpack 5 在输出配置中增加了 output.trustedTypes 选项。开启后，webpack 的运行时代码会使用 window.trustedTypes.createPolicy 创建可信脚本对象，避免违反 CSP 中的 require-trusted-types-for 'script' 指令。基本配置如下：
module.exports = {
output: {
trustedTypes: {
policyName: 'webpack-5-security-policy',
},
},
};
策略名需要与 CSP 响应头中的 trusted-types 指令保持一致。例如服务端可以返回这样的 CSP 头：Content-Security-Policy: require-trusted-types-for 'script'; trusted-types webpack-5-security-policy;。如果策略名不一致，运行时创建的脚本会被浏览器拦截，导致 chunk 加载失败。建议使用显式的 policyName，避免使用默认策略名时与团队内多个项目产生混淆。
需要注意的是，开启 Trusted Types 要求浏览器支持该 API。对于不支持的旧浏览器，webpack 会保留原有加载路径，不会强制依赖。因此在渐进增强的场景下可以安全开启。与此同时，生产环境应当避免使用 eval 类型的 devtool，因为 eval 本身与严格 CSP 冲突，也容易泄露源码逻辑。
全局 chunk 加载变量唯一化，防止多应用冲突劫持
Webpack 4 的运行时会在全局注册一个名为 webpackJsonp 的数组，用于异步 chunk 的加载与缓存。这个变量名是固定且公开的。如果同一个页面同时加载了多个由 webpack 构建的应用，后加载的运行时会覆盖或复用同一个全局数组，轻则导致模块重复注册、加载错乱，重则被页面上的其他脚本提前挂钩 webpackJsonp.push，在 chunk 加载时注入恶意代码。
Webpack 5 默认不再使用固定的 webpackJsonp，而是根据 output.uniqueName 生成一个唯一的全局加载变量。即使你没有手动配置，webpack 也会尝试从 package.json 的 name 字段或目录名中推导。多应用共存时，只要保证 uniqueName 不同，各自的运行时代码就不会发生全局变量冲突。如需手动控制，可以这样设置：
module.exports = {
output: {
uniqueName: 'app-a',
chunkLoadingGlobal: 'appAChunkLoader',
},
};
这一变化与模块联邦场景关系密切。使用模块联邦时，多个独立构建的容器可能运行在同一个页面中，如果全局加载变量发生冲突，不仅影响模块加载，还可能形成跨应用的执行劫持入口。通过唯一化的 uniqueName 和对应的 chunk 加载命名空间，各容器之间的运行时边界更加清晰，降低了意外共享全局状态带来的安全风险。
实际项目中的安全落地顺序
这些安全特性并不是开启越多越好，而是要结合应用场景逐步落地。首先可以优先升级到 Webpack 5，并处理 Node 核心模块 polyfill 的显式配置。这个变化直接减少了浏览器环境中的全局对象数量，属于收益明显且侵入性较低的调整。
接着评估生产环境是否已经启用了严格 CSP。如果 CSP 尚未启用，可以先将 Trusted Types 作为目标之一，在测试环境验证 webpack 运行时加载 chunk 是否正常。最后再处理多应用同页部署或模块联邦场景下的全局变量隔离问题，通过 output.uniqueName 为每个构建产物划定独立命名空间。
构建工具的安全能力往往不如运行时防护那么显眼，但它的作用是在源头收紧默认行为。Webpack 5 在安全方面的改动，总体上遵循了一个原则：不再替开发者做过多隐式假设，而是把高风险能力显式化、把全局变量唯一化，让安全边界在构建阶段就变得更加清晰。
Webpack 5安全特性Trusted Types修改时间：2026-09-27 06:20:03