Chrome扩展无法通过webRequest为HTML import请求添加Cookie头的问询

这是个很典型的跨浏览器扩展开发痛点，我来帮你拆解下情况和可行的解决思路：

一、这是规范行为还是Chrome的Bug？ #

首先明确：Chrome当前的表现符合HTML Imports的规范要求。

HTML import规范明确规定，这类资源采用同源模式的CORS策略获取，默认不会发送凭证信息（包括Cookie），Chrome严格遵循了这一规则，所以原生加载流程里不带Cookie是标准行为。

但这里的核心矛盾是浏览器对扩展权限的边界定义不同：Firefox允许扩展通过webRequest.onBeforeSendHeaders强制注入Cookie头，而Chrome目前的安全策略不允许突破这个原生CORS限制——这属于厂商间的实现差异，暂时不能直接定性为Chrome的Bug。

你提到Chromium团队正在考虑放宽部分扩展安全限制，这个方向非常对，你提交的问题很可能会推动这个场景的权限调整，建议持续跟进。

二、可行的Workaround方案 #

针对Chrome当前的限制，有几个可以落地的思路：

1. 绕过HTML Imports，改用自定义加载方式

既然原生HTML Imports的加载机制受限于CORS凭证规则，不如直接替换它：

• 用fetch API（配置credentials: 'include'）手动拉取导入的HTML内容，再通过DOM操作插入页面
• 或者用XHR请求（设置withCredentials = true）获取资源后处理，这样能主动带上Cookie，完全避开原生Imports的限制

2. 调整远程资源的服务端配置

如果你有权限修改远程服务的话：

• 把需要被Imports的资源设置为同源资源（和主页面同域名），这样原生加载就会自动携带Cookie
• 或者修改CORS配置，允许你的扩展对应的来源携带凭证（同时确保请求端设置了credentials相关参数）

3. 尝试用declarativeNetRequest替代webRequest

Chrome的declarativeNetRequest API权限模型和webRequest略有不同，部分场景下可能允许添加Cookie头。你可以创建这样的规则：

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders": [
      { "header": "Cookie", "operation": "set", "value": "your-cookie-content" }
    ]
  },
  "condition": {
    "urlFilter": "*your-remote-resource-path*",
    "resourceTypes": ["sub_frame"] // HTML Imports通常属于sub_frame类型
  }
}

记得在扩展清单里声明declarativeNetRequest权限，同时要保证Cookie值的获取和传递符合Chrome的安全要求。

4. 注入内容脚本拦截原生Imports请求

在内容脚本里监听页面的HTML Imports加载事件，拦截原生请求后用自定义的带凭证请求获取资源，再模拟Imports的效果插入页面。比如监听HTMLImportsLoaded事件，或者直接拦截<link rel="import">元素的加载行为，替换成自己的请求逻辑。

总结 #

Chrome当前的行为是遵循规范的，但扩展权限限制导致你无法通过webRequest注入Cookie头，这是浏览器间的实现差异。上面的几个Workaround可以根据你的实际场景选择，同时你提交的Chromium问题是推动这个场景优化的关键，建议持续跟进。

内容的提问来源于stack exchange，提问作者user1706698