引言一个让前端老手集体破防的 CORS 报错你是一个熟悉 JavaScript 与 Web 前端开发的老手React 写了三年Vue 用了五年fetch 请求闭着眼都能写。但第一次接触 Chrome 扩展开发时你被一个看似简单的架构决策卡住了——为什么我的 Content Script 发起的 API 请求被 CORS 拦下来了// content_script.jsconsttokenawaitchrome.storage.local.get(token);fetch(https://api.crm.com/user,{headers:{Authorization:Bearer${token}}});运行然后在控制台看到一个熟悉的报错Access to fetch at https://api.crm.com/user from origin https://web.whatsapp.com has been blocked by CORS policy更让人头疼的是你刚学会 Manifest V3 中“后台脚本”变成了“Service Worker”就听说 Chrome 会在闲置 30 秒后把它杀掉。那我的 WebSocket 长连接怎么办Token 会不会丢跨域请求到底怎么搞本文将从 MV3 的实际约束出发系统性地剖析 Chrome 扩展中 CORS 绕过的两种核心策略——background.js 代理与原生消息传递Native Messaging并深入探讨架构设计、安全风险、竞品对比与生态工具。一、先认识三个核心角色Chrome 扩展的“阶级划分”在深入 CORS 绕过之前必须先理解 Chrome 扩展中不同组件的权限差异。角色运行环境可访问 DOM可绕过 CORSBackground Service Worker扩展独立后台❌✅通过 host_permissionsContent Script宿主页面 DOM✅❌Popup / Options独立页面✅自身页面❌关键记忆Content Script 住在别人家里Background SW 住在扩展自己的房间里。这个“阶级划分”是整个 CORS 绕过策略的底层逻辑——不同组件拥有完全不同的网络请求权限。二、MV3 的 CORS 铁律为什么你绕不开 Background2.1 Content Script 的 CORS 困境Content Script 的fetch()遵循宿主页面的源Origin。当它请求一个跨域 API 时浏览器会发送 CORS 预检并要求目标服务器返回允许该宿主域的Access-Control-Allow-Origin头。绝大多数情况下你无法控制第三方 API 后端去允许所有可能的宿主页面如web.whatsapp.com、mail.google.com等。这就是为什么 Content Script 直接发请求几乎总是被 CORS 拦截。2.2 Background Service Worker 的特权Background Service Worker 完全不同。它在扩展自己的上下文chrome-extension://extension-id中运行并且你在manifest.json中声明了host_permissions后Background 发起的请求完全绕过 CORS 检查——浏览器信任扩展如同信任本地系统服务。// manifest.json{manifest_version:3,host_permissions:[https://api.crm.com/*,https://api.openai.com/*]}配置了这个之后你的 Service Worker、popup 页面或者 options 页面里的 fetch 请求只要目标是声明中的域名及其子路径就都会被放行。2.3 核心结论无论 Token 放在哪里所有跨域 API 调用都必须经由 Background 代理——这不是一个选项而是一个强制约束。在 MV3 中所有跨域 API 调用都必须经过 Background SW 代理——这不是“最佳实践”的选择题而是“能不能工作”的是非题。三、策略一background.js 代理——最经典的 CORS 绕过方案3.1 架构设计消息驱动的代理模式Background 代理的核心架构是一个消息驱动的请求转发系统Content Script / Popup ↓ chrome.runtime.sendMessage({ type: PROXY_FETCH, url, options }) Background Service Worker ↓ fetch(url, options) —— 绕过 CORS ↓ 返回响应 Content Script / Popup ↓ 收到响应数据3.2 完整代码实现Background Service Workerbackground.js// background.js - Manifest V3 Service Workerchrome.runtime.onMessage.addListener((message,sender,sendResponse){if(message.typePROXY_FETCH){const{url,options{}}message.payload;// 直接 fetch——绕过 CORSfetch(url,{...options,headers:{...options.headers,// 可以在这里统一注入 Token}}).then(asyncresponse{constdataawaitresponse.json();sendResponse({success:true,data,status:response.status});}).catch(error{sendResponse({success:false,error:error.message});});returntrue;// 保持消息通道开放以支持异步响应}});Content Scriptcontent_script.js// content_script.jsfunctionproxyFetch(url,options{}){returnnewPromise((resolve,reject){chrome.runtime.sendMessage({type:PROXY_FETCH,payload:{url,options}},(response){if(chrome.runtime.lastError){reject(newError(chrome.runtime.lastError.message));return;}if(response.success){resolve(response.data);}else{reject(newError(response.error));}});});}// 使用方式——和普通 fetch 一模一样constuserDataawaitproxyFetch(https://api.crm.com/user);3.3 真实案例FranzAI Bridge V2根据 Extpose 平台上的公开信息FranzAI Bridge V2 是一个开发者工具 Chrome 扩展它通过扩展后台 Service Worker 路由 API 请求从而绕过浏览器 CORS 限制访问任何端点。其核心特性包括CORS 绕过通过扩展后台 Service Worker 路由 API 请求API Key 注入按域名安全地注入 API 密钥密钥保留在扩展中永不暴露在客户端 JavaScript 中流式支持完整支持 SSE 和流式响应兼容 OpenAI、Gemini、Claude 及任意流式 API请求检查器内置侧边栏实时显示所有请求的状态码、耗时、请求头和响应体预览这个案例证明了 Background 代理方案在生产环境中的可行性和成熟度。3.4 Token 管理的三层架构根据 CSDN 上近期2026年6月的深度分析Token 管理在 Background 代理架构中有三种方案方案 AToken 隔离在 Background推荐Token 持久化存在chrome.storage跨上下文、可同步内存缓存SW 存活时直接使用内存变量冷启动恢复SW 被终止后重新启动时从 storage 重新读取方案 BToken 在 Content Script 直接使用不可行即使忽略 CORSToken 会在消息中明文传递理论上可被其他扩展监听方案 C混合方案Token 每次由 CS 传给 BG可行但啰嗦每次请求都要从 storage 异步读取增加延迟四、策略二Native Messaging——从浏览器到操作系统的桥梁当 Background 代理还不够用时——比如需要访问本地文件系统、调用系统级 API、或与本地服务通信——Native Messaging就是终极方案。4.1 什么是 Native Messaging根据 Chrome 官方文档Native Messaging 允许扩展与本地安装的可执行程序进行双向通信。Chrome 将每个 Native Messaging Host 启动在独立进程中通过标准输入stdin和标准输出stdout与它通信。Native Messaging channels始终强制使用 JSON 序列化。尝试向原生宿主发送仅结构化克隆支持的类型如BigInt会在消息离开扩展上下文之前失败。4.2 架构设计扩展 ↔ 本地宿主Chrome 扩展 ↓ chrome.runtime.connectNative(com.example.native_host) Native Messaging Host独立进程 ↓ stdin / stdout 本地系统资源文件、硬件、本地服务4.3 完整实现步骤第一步编写 Native Messaging Host以 Node.js 为例// native_host.jsconstreadlinerequire(readline);constrlreadline.createInterface({input:process.stdin,output:process.stdout,terminal:false});// 读取消息Chrome 使用 4 字节长度前缀 JSONletbufferBuffer.alloc(0);rl.on(line,(line){try{constmessageJSON.parse(line);console.error([Native Host] Received:${JSON.stringify(message)});// 处理请求constresponse{type:response,payload:{echo:message.payload,timestamp:Date.now()}};// 发送响应同样需要 4 字节长度前缀constresponseStrJSON.stringify(response);constlengthBufferBuffer.alloc(4);lengthBuffer.writeUInt32LE(Buffer.byteLength(responseStr),0);process.stdout.write(Buffer.concat([lengthBuffer,Buffer.from(responseStr)]));}catch(e){console.error([Native Host] Error:${e.message});}});第二步创建 Native Messaging Host Manifest// com.example.native_host.json{name:com.example.native_host,description:Example Native Messaging Host,path:/usr/local/bin/native_host.js,type:stdio,allowed_origins:[chrome-extension://YOUR_EXTENSION_ID/]}第三步安装 Native Messaging Host根据平台不同manifest 文件需要放到特定目录平台路径Linux~/.config/[browser-name]/NativeMessagingHosts/macOS~/Library/Application Support/[Browser]/NativeMessagingHosts/Windows%APPDATA%\[Browser]\NativeMessagingHosts\第四步扩展中连接 Native Host// background.jsletnativePortnull;functionconnectToNativeHost(){if(nativePort)return;nativePortchrome.runtime.connectNative(com.example.native_host);nativePort.onMessage.addListener((message){console.log(Received from native host:,message);// 处理来自本地宿主的消息});nativePort.onDisconnect.addListener((){console.error(Native host disconnected:,chrome.runtime.lastError);nativePortnull;// 尝试重连setTimeout(connectToNativeHost,5000);});// 发送消息到本地宿主nativePort.postMessage({type:request,payload:{action:readFile,path:/tmp/data.txt}});}chrome.runtime.onStartup.addListener(connectToNativeHost);4.4 2026 年 Native Messaging 生态MCP 与 AI Agent 集成2026 年Native Messaging 最引人注目的应用场景是MCPModel Context Protocol与 AI Agent 的集成。根据 npm 上的公开包信息zyzheal/chrome-mcp通过 Chrome Native Messaging 协议与 Chrome 扩展进行双向通信提供 MCP 服务支持 AI Agent 通过 stdio 协议控制浏览器。其架构为AI Agent (Claude/Cursor) ↓ (stdio 协议) mcp-chrome-stdio (MCP 代理) ↓ (HTTP Streamable) Chrome 扩展中的 MCP 服务器 ↓ (Native Messaging) chrome-mcp (本地服务) ↓ Chrome 浏览器操作另一个开源项目mcp-chrome-bridger提供了类似的 Native Messaging Host支持 Chrome 和 Chromium 在 Linux、macOS 和 Windows 上的多浏览器注册。其 CLI 工具支持自动检测并注册所有已安装的浏览器。neurodock/native-host2026年6月19日发布则展示了另一个方向——通过 Native Messaging 将本地配置文件~/.neurodock/profile.yaml暴露给浏览器扩展支持 Chrome、Chromium、Brave、Edge、Vivaldi 和 Firefox 等多浏览器。这意味着Native Messaging 正在成为连接 AI 世界与浏览器世界的核心桥梁。五、安全风险特权越大责任越大CORS 绕过能力是一把双刃剑。Background 代理和 Native Messaging 赋予扩展的巨大权限如果被恶意利用后果不堪设想。5.1 近期安全漏洞2026 年CVE-2026-12456根据 VulDB 和 NVD 的记录Google Chrome 149.0.7827.155 之前的版本存在一个扩展程序漏洞。攻击者通过诱使用户安装恶意 Chrome 扩展可以绕过同源策略Same Origin Policy。该漏洞被归类为“不恰当实现”Inappropriate implementation。修复版本为149.0.7827.155或更高版本。CVE-2026-11048另一个影响 Chrome 扩展组件的跨域策略漏洞于 2026 年 6 月 5 日被记录。CVE-2026-11212该漏洞源于 Chrome DevTools 中策略执行不足使恶意扩展能够绕过跨域数据限制。成功利用此漏洞的攻击者可以泄露跨域数据可能暴露用户访问的其他网站或 Web 应用中的敏感信息。5.2 阿里云漏洞库披露的深层问题根据阿里云漏洞库的信息Chrome 扩展模块负责运行扩展程序并控制网络请求行为。在受影响版本中extensions/browser/url_loader_factory_manager.cc的ShouldRelaxCors函数存在逻辑错误。更严重的是当渲染进程被入侵后攻击者可通过伪造参数绕过同源策略限制伪装成其他扩展身份注册事件监听器从而访问本不属于该扩展的 origins。修复版本中通过在EventRouter中添加多项授权检查来消除该漏洞。5.3 安全实践建议最小权限原则host_permissions只声明必需的域名不要使用all_urlsNative Messaging Host 验证Native Host 应验证调用它的扩展 ID敏感数据不落地Token 等敏感信息存储在chrome.storage.local不要写入本地文件及时更新 Chrome保持浏览器在最新版本≥ 149.0.7827.155CSP 策略在 manifest.json 中配置严格的 Content Security Policy六、架构设计深度对比6.1 两种策略的全面对比维度Background 代理Native Messaging权限范围仅限网络请求HTTP/HTTPS完整操作系统访问部署复杂度低纯 JS无需额外安装高需安装本地可执行文件跨平台支持天然跨平台需为每个平台编译/打包性能开销极低消息传递 fetch中等进程间通信适用场景API 代理、CORS 绕过文件系统、硬件、本地服务安全风险中CORS 绕过可能被滥用高完整系统访问调试难度低Chrome DevTools 可直接调试高需查看本地日志6.2 何时选择 Background 代理只需要调用第三方 HTTP API希望扩展轻量、易于分发不需要访问本地系统资源目标用户是非技术用户不愿安装额外软件6.3 何时选择 Native Messaging需要读写本地文件系统需要调用系统级 API如硬件设备、系统命令需要与本地运行的服務如数据库、AI 模型通信构建 AI Agent 与浏览器的桥梁MCP 场景需要高性能、低延迟的本地计算七、竞品对比Chrome vs Firefox 的 CORS 绕过策略7.1 Firefox 扩展的 CORS 绕过Firefox 扩展生态中也有类似的 CORS 绕过方案。根据 Mozilla 附加组件商店的信息Safe CORS2026年3月14日发布允许开发者按标签页绕过 CORS 限制完全由页面脚本控制。与传统的工具栏切换全局禁用 CORS 不同Safe CORS 从你的代码中编程式激活——非常适合本地开发和测试。CORS Unbound2026年4月19日发布是一个 Firefox 扩展它绕过 CORS 限制并直接在浏览器内部重写 HTTP 请求/响应头。它专为本地开发、原型设计、自动化、爬虫和高级调试而设计——完全不需要运行服务器。Sources to Folders2026年1月29日发布则在扩展后台执行 fetch绕过 CORS正确下载跨域资源CDN。7.2 Chrome vs Firefox核心差异维度Chrome (MV3)Firefox后台脚本Service Worker无 DOM30秒可被终止持久化后台页面有 DOMCORS 绕过方式host_permissions Background SW扩展后台页面 WebRequest APINative Messaging支持JSON 序列化强制支持但有兼容性差异扩展审核Chrome Web Store 审核相对宽松7.3 跨浏览器 Native Messaging 的兼容性挑战根据guest271314/native-messaging-nodejs的文档不同操作系统和浏览器在 Native Messaging 实现上存在差异。开发者需要参考 Chrome 不兼容性文档 来处理这些差异。好消息是越来越多的 Native Messaging Host 项目开始主动支持多浏览器。neurodock/native-host明确支持 Chrome、Chromium、Brave、Edge、Vivaldi 和 Firefox。八、2026 年最新动态结构化克隆与消息传递的革新8.1 Chrome 148 的重大更新根据 Chrome for Developers 官方博客2026年4月22日发布从 Chrome 148 开始扩展开发者可以选择使用结构化克隆算法进行消息序列化而不是 JSON这一现代化方法让你可以在扩展上下文之间发送更复杂的数据类型而无需手动序列化变通方法。JSON 序列化的问题// 发送 Map——JSON 序列化后变成 {}constmyMapnewMap([[id,123]]);chrome.runtime.sendMessage(myMap);// 另一端收到的是 {}// 变通方案手动转换constmessageArray.from(myMap.entries());chrome.runtime.sendMessage(message);// 接收端再转回 Map结构化克隆的解决方案// 直接发送 Map——抵达时仍是 Map 实例constmyMapnewMap([[id,123]]);chrome.runtime.sendMessage(myMap);// 接收端message 已经是 Map 实例console.log(message.get(id));// 1238.2 如何启用结构化克隆在manifest.json中添加一个键即可全局启用{name:My Extension,version:1.0,manifest_version:3,message_serialization:structured_clone}如果省略此键或在 Chrome 148 以下版本浏览器默认为基于 JSON 的实现。8.3 支持的更多类型结构化克隆支持比 JSON 更广泛的类型包括File、Blob、Set、BigInt、NaN、Infinity、Date和Error对象。但不支持SharedArrayBuffer和可传输对象如ArrayBuffer——尝试发送Uint8Array将发送副本而非传输。8.4 对 CORS 绕过架构的影响结构化克隆对 Background 代理架构的直接影响在于Content Script 与 Background 之间的消息传递可以携带更丰富的数据类型。例如在代理请求时可以直接传递FormData、Blob或File对象而无需手动序列化// Content ScriptconstformDatanewFormData();formData.append(file,fileInput.files[0]);// 直接发送 FormData——结构化克隆支持chrome.runtime.sendMessage({type:PROXY_FETCH,payload:{url:https://api.example.com/upload,options:{method:POST,body:formData}}});这大大简化了文件上传等复杂场景的实现。九、生态工具与部署方案9.1 主流开发框架与工具链WXT Framework根据 DeepWiki 上的项目文档Chrome 扩展使用 Manifest V3 并通过 WXT 框架的配置文件进行配置。WXT 定义了权限、入口点以及浏览器自动化和 MCP 服务器功能所需的安全策略。WXT 正在成为 2026 年 Chrome 扩展开发的事实标准框架类似于前端开发中的 Vite。9.2 Native Messaging Host 部署工具工具发布时间核心功能zyzheal/chrome-mcp2026-04-15MCP 服务 Native MessagingAI Agent 控制浏览器mcp-chrome-bridger2026-01-24多浏览器注册 TypeScript 实现neurodock/native-host2026-06-19多浏览器支持6 种浏览器guest271314/native-messaging-nodejs2026-06-21Node.js/Deno/Bun 原生宿主9.3 部署检查清单Background 代理方案部署✅ 在manifest.json中声明host_permissions✅ 在background.js中实现消息监听与 fetch 代理✅ 在 Content Script 中使用chrome.runtime.sendMessage调用代理✅ 配置message_serialization: structured_cloneChrome 148✅ 测试跨域请求是否正常Native Messaging 方案部署✅ 编写 Native Messaging Host 可执行文件✅ 创建 Native Host ManifestJSON✅ 将 Manifest 安装到系统对应目录✅ 在扩展中使用chrome.runtime.connectNative连接✅ 使用chrome-mcp doctor诊断安装问题✅ 使用chrome-mcp fix-permissions修复权限问题十、实践建议与趋势判断10.1 架构选型决策树是否需要访问本地系统资源 ├── 否 → Background 代理方案 │ ├── 是否需要传输复杂数据类型Map、File、Blob │ │ ├── 是 → 启用 structured_cloneChrome 148 │ │ └── 否 → JSON 序列化即可 │ └── Token 管理 → 方案 AToken 隔离在 Background │ └── 是 → Native Messaging 方案 ├── 是否需要 AI Agent 集成 │ ├── 是 → 使用 MCP Chrome Native Messaging │ └── 否 → 自定义 Native Host └── 是否需要多浏览器支持 ├── 是 → 使用 neurodock/native-host 等成熟方案 └── 否 → 自定义实现10.2 核心实践建议永远不要把 API Key 写在 Content Script 里——它在客户端完全可见所有跨域请求都必须经过 Background——这不是可选项Native Messaging Host 必须验证调用者身份——防止其他恶意扩展滥用保持 Chrome 更新到最新版本——至少 ≥ 149.0.7827.155善用结构化克隆——Chrome 148 让消息传递更强大使用成熟的 Native Messaging 工具——不要重复造轮子10.3 2026 年趋势判断趋势一MCP Native Messaging 成为 AI 浏览器自动化的标准路径从zyzheal/chrome-mcp、mcp-chrome-bridger到neurodock/native-host2026 年上半年涌现了大量将 AI Agent 与 Chrome 扩展通过 Native Messaging 连接的开源项目。这标志着Native Messaging 正在从“小众技术”走向“AI 基础设施”。趋势二结构化克隆将重塑扩展消息传递的范式Chrome 148 引入的结构化克隆支持使扩展开发者可以告别 JSON 序列化的种种限制。预计在未来 6-12 个月内主流扩展框架和工具链将全面适配这一特性。趋势三跨浏览器 Native Messaging 走向成熟从仅支持 Chrome到支持 Chromium、Brave、Edge、Vivaldi 乃至 FirefoxNative Messaging Host 的跨浏览器支持正在快速完善。这为构建“一次开发多浏览器部署”的扩展提供了可能。趋势四安全审查将持续收紧CVE-2026-12456、CVE-2026-11048、CVE-2026-11212 等一系列 2026 年披露的漏洞表明Chrome 扩展的安全审查将越来越严格。开发者需要将安全左移——在架构设计阶段就考虑权限最小化、输入验证和通信加密。结语Chrome 扩展的 CORS 绕过从来不是一个“技巧”而是一个架构设计问题。Background 代理方案让你在 Web 标准框架内解决跨域问题而 Native Messaging 则打开了从浏览器到操作系统的大门。两者各有适用场景并非相互替代而是互补共存。2026 年的 Chrome 扩展开发生态正在经历深刻的变革——Manifest V3 的全面普及、结构化克隆的引入、MCP 与 AI Agent 的深度融合——每一个变化都在重新定义“最佳实践”的内涵。记住权限越大责任越大。善用 Background 代理与 Native Messaging但永远把用户安全放在第一位。本文引用的信息来源包括Chrome for Developers 官方博客2026年4月22日、CSDN 技术社区2026年6月、VulDB 漏洞数据库2026年6月、NVD 国家漏洞数据库2026年6月、npm 包发布信息2026年4-6月、Extpose 扩展平台2026年2月、Mozilla 附加组件商店2026年3-4月等。所有代码示例均基于 Manifest V3 规范。