示例工程【免费下载链接】chrome-extensions-samplesChrome Extensions Samples项目地址https://gitcode.com/gh_mirrors/ch/chrome-extensions-samples点击查看免费下载本文基于 chrome-extensions-samples 仓库中_archive/apps/samples/sandboxed-content示例讲解 Chrome 打包应用Packaged App默认 CSP 禁止eval()的约束下如何通过sandbox清单字段将页面放入沙箱化 iframe 中执行受限代码并结合仓库中的姊妹示例_archive/apps/samples/sandbox展示沙箱化页面与主页面之间通过postMessage通信的完整实战模式。读完本文你将掌握sandbox字段的声明方法、沙箱化页面与主窗口的代码组织方式、以及基于消息传递的安全协作范式。背景为什么需要沙箱化内容Chrome 打包应用Packaged AppManifest V2 时代的app类型应用默认执行一套严格的 Content Security PolicyCSP。在这套默认策略下应用内部禁止使用eval()、new Function()以及Function.apply()等动态代码执行变体。这一限制的目的是消除字符串即代码注入面防止应用在遭遇 XSS 等攻击时被完全接管。然而现实中仍有大量合法场景需要动态求值能力典型代表包括基于字符串拼装 HTML 片段并写入文档使用 Handlebars、Underscore、EJS 等依赖new Function()编译模板的模板引擎运行第三方 JS 库如某些混淆代码、计算器引擎时其内部依赖eval。示例文档明确指出由于默认 CSP 禁止这些能力使用沙箱sandbox机制是该场景下的必要手段。沙箱的职责是把不安全的代码关进笼子里而不是放宽整个应用的安全策略——这正是沙箱化内容设计的核心思想。示例总览一个最简单的沙箱演示_archive/apps/samples/sandboxed-content示例构建了一个包含主窗口和沙箱化 iframe 的应用主窗口main.html显示 Main Window声明自己不是沙箱化的主窗口内嵌一个 380×140 的 iframe加载沙箱化页面sandboxed.html沙箱化页面内通过eval()执行一段内联脚本向自己的#message容器写入 HTML 文本。该示例触及的 API 只有 Runtime应用启动生命周期是最小可运行的沙箱演示。运行时界面见示例的截图 assets/screenshot_1280_800.png。核心配置清单文件中的sandbox字段沙箱机制的开关完全由应用的清单文件manifest.json控制。示例的 manifest.json 内容如下{ name: Sandboxed Content Sample, version: 1.0.2, manifest_version: 2, minimum_chrome_version: 23, app: { background: { scripts: [main.js] } }, icons: { 128: icon_128.png }, sandbox: { pages: [sandboxed.html] } }关键点字段值说明manifest_version2打包应用时代的清单版本MV2minimum_chrome_version23沙箱化页面能力自 Chrome 23 起可用app.background.scripts[main.js]应用后台脚本负责创建窗口sandbox.pages[sandboxed.html]声明哪些页面被放入沙箱被声明的页面将不再受应用默认 CSP 约束允许使用eval()等动态执行能力关键语义sandbox.pages中列出的每个页面都会被加载到带唯一随机来源unique origin的沙箱化 iframe 中。沙箱页面拥有相对宽松的 CSP允许脚本与eval但付出的代价是无法直接访问chrome.*API如chrome.app.*、chrome.runtime.*不能访问 DOM 存储localStorage、sessionStorage等需要权限的资源与主页面之间只能通过受限的消息通道交互见下文通信范式一节。一个典型误区是在sandbox.pages中同时列出主页面这没有必要也不正确——沙箱只应包裹那些确实需要动态求值的页面。在示例中只有sandboxed.html需要eval因此只有它被列入沙箱。应用启动流程与窗口创建应用入口是清单中声明的后台脚本 main.js它通过 Runtime API 监听启动事件并创建主窗口chrome.app.runtime.onLaunched.addListener(function() { chrome.app.window.create(main.html, { id: mainwin, innerBounds: {width: 400, height: 350} }); });chrome.app.runtime.onLaunched应用被用户启动时触发对应文档中列出的 Runtime APIchrome.app.window.create创建应用窗口加载main.html作为窗口内容innerBounds: {width: 400, height: 350}指定窗口初始尺寸配合主窗口内 iframe 的width380 height140两者基本吻合保证沙箱内容完整可见。沙箱化页面eval 在这里被允许沙箱化页面 sandboxed.html 的核心是一个调用eval()的内联脚本body h1Sandboxed Content/h1 pI am the sandboxed iframe./p div idmessage/div script eval(document.getElementById(\message\).innerHTML \pI am the output of an eval-ed inline script./p\); /script /body在普通的打包应用中这段内联脚本会直接违反默认 CSP 而被拒绝执行正是因为该页面被列入了sandbox.pages浏览器才允许其运行。执行后#message容器内会插入一段p文本页面标题下方出现 I am the output of an eval-ed inline script. 一行内容。注意沙箱化 iframe 本身没有沙箱 HTML 属性sandbox限制——它只是通过 manifest 声明获得的沙箱化页面身份而不是 HTML5 原生 iframe sandbox 特性两者不要混淆。进阶实战沙箱内运行 Handlebars 模板引擎并通过 postMessage 协作仅靠eval拼字符串只是入门。仓库中同目录下的姊妹示例 sandboxSandboxed Frame Sample展示了沙箱机制的完整实战价值在沙箱化 iframe 中加载 Handlebars 模板库由主页面通过postMessage传入数据沙箱页面完成模板编译与渲染后把结果回传主页面。该示例的 manifest.json 将sandbox.html声明为沙箱页面sandbox: { pages: [sandbox.html] }沙箱页面预编译模板并监听消息沙箱页面 sandbox.html 中通过script srchandlebars-1.0.0.beta.6.js引入 Handlebars 模板库。Handlebars 编译模板时依赖new Function()动态生成渲染函数这正是它必须运行在沙箱内的原因页面加载时用Handlebars.compile(source)将两个text/x-handlebars-template脚本块预编译为模板函数templates[name] Handlebars.compile(source);注册window.addEventListener(message, ...)监听来自外层框架的消息根据event.data.templateName选取模板、以event.data.context为数据调用模板渲染并通过event.source.postMessage({result: result}, event.origin)把结果回传调用方若模板名未知则返回Unknown template: ...错误信息。主页面postMessage 请求与结果接收主页面 mainpage.html 内嵌一个隐藏的 iframestyledisplay: none;来承载沙箱其逻辑在 mainpage.js 中document.getElementById(sendMessage).addEventListener(click, function(event) { counter; var message { command: render, templateName: sample-template- counter, context: {counter: counter} }; document.getElementById(theFrame).contentWindow.postMessage(message, *); }); // on result from sandboxed frame: window.addEventListener(message, function(event) { document.querySelector(#result).innerHTML event.data.result || invalid result });工作流程为点击按钮 → 计数器自增 → 主页面通过contentWindow.postMessage(message, *)向沙箱 iframe 发送{command, templateName, context}→ 沙箱页面用{{counter}}占位符渲染出 Hello / Welcome back 模板 → 结果回传 → 主页面将渲染后的 HTML 写入#result。两个模板分别对应奇数/偶数计数直观演示了同一沙箱服务多个模板的能力。通信范式的通用要点从两个示例可以提炼出沙箱化页面的协作范式单向能力隔离所有不安全的动态求值eval、模板编译都收敛在沙箱页面内部完成消息驱动主页面→沙箱用contentWindow.postMessage沙箱→主页面用event.source.postMessage入参出参皆为纯数据context只携带可序列化数据沙箱结果同样以字符串/数据形式返回主页面只负责 DOM 写入不接触不安全代码示例中使用postMessage(message, *)属于简化演示写法生产环境应指定明确的 targetOrigin并在沙箱侧校验event.origin。何时使用沙箱、注意事项与限制适用场景需要在内置页面中使用eval()/new Function()典型如模板引擎Handlebars、Underscore、EJS、运行时动态编译、第三方依赖eval的库等。限制清单从源码结构与 manifest 声明可以确认沙箱页面无法访问chrome.*扩展/应用 API无法直接使用localStorage等存储能力必须由主窗口通过消息中继沙箱页面的唯一随机来源意味着它与应用其他部分天然隔离不能直接共享 DOM 或 JavaScript 作用域只有被列入sandbox.pages的页面才获得宽松 CSP未被列入的页面仍受默认 CSP 严格约束绝不能把整个应用页面全部声明为沙箱否则会失去 CSP 防护意义该机制适用于 Manifest V2 时代的打包应用示例manifest_version为 2Chrome 23 可用MV3 扩展已无内置页面沙箱字段属于历史归档用法本文所有路径位于仓库_archive归档目录仅供学习参考。总结sandboxed-content示例用最小代码量演示了打包应用沙箱机制的完整链路manifest.json的sandbox.pages声明 → 主窗口嵌入沙箱化 iframe → 沙箱页面内自由使用eval()。而sandbox示例进一步展示了它的工业级用法在沙箱内运行依赖new Function()的 Handlebars 模板引擎并借助postMessage实现主页面与沙箱之间的安全数据交换。沙箱机制的本质是在不放松整个应用 CSP 的前提下为确实需要动态求值能力的代码开辟一个受控的隔离执行区——这是理解 Chrome 应用安全模型的重要一环。参考资源仓库内沙箱化内容示例README.md、manifest.json、sandboxed.html、main.js、main.htmlHandlebars 沙箱协作示例README.md、sandbox.html、mainpage.js、mainpage.html界面截屏sandboxed-content/assets/screenshot_1280_800.png、sandbox/assets/screenshot_1280_800.png赞分享示例工程【免费下载链接】chrome-extensions-samplesChrome Extensions Samples项目地址https://gitcode.com/gh_mirrors/ch/chrome-extensions-samples点击查看免费下载相关推荐在 Chrome 打包应用中使用 Dart以 chrome-extensions-samples 的 Dart 时钟应用为例在 Chrome 打包应用中使用 Dart以 chrome extensions samples 的 Dart 时钟应用为例 本篇技术指南以 chrome e示例工程在 Chrome 打包应用中运行 TCP 服务器解析 chrome-extensions-samples 的 Chrome Commando 示例在 Chrome 打包应用中运行 TCP 服务器解析 chrome extensions samples 的 Chrome Commando 示例 导读 本篇示例工程Chrome 扩展 MV3 沙箱机制实战基于 chrome-extensions-samples 在 sandbox.html 中安全运行 Handlebars 模板Chrome 扩展 MV3 沙箱机制实战基于 chrome extensions samples 在 sandbox.html 中安全运行 Handlebar示例工程上一篇10分钟上手curlconverter从命令行到代码的无缝转换下一篇嵌入式系统静态分析从0到1构建代码安全审计体系创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/21 15:07:32 · 阅读 1.2k chrome-extensions-samples 沙箱化内容示例：在 Chrome 打包应用中安全使用 eval 与模板引擎
示例工程【免费下载链接】chrome-extensions-samplesChrome Extensions Samples项目地址https://gitcode.com/gh_mirrors/ch/chrome-extensions-samples点击查看免费下载本文基于 chrome-extensions-samples 仓库中_archive/apps/samples/sandboxed-content示例讲解 Chrome 打包应用Packaged App默认 CSP 禁止eval()的约束下如何通过sandbox清单字段将页面放入沙箱化 iframe 中执行受限代码并结合仓库中的姊妹示例_archive/apps/samples/sandbox展示沙箱化页面与主页面之间通过postMessage通信的完整实战模式。读完本文你将掌握sandbox字段的声明方法、沙箱化页面与主窗口的代码组织方式、以及基于消息传递的安全协作范式。背景为什么需要沙箱化内容Chrome 打包应用Packaged AppManifest V2 时代的app类型应用默认执行一套严格的 Content Security PolicyCSP。在这套默认策略下应用内部禁止使用eval()、new Function()以及Function.apply()等动态代码执行变体。这一限制的目的是消除字符串即代码注入面防止应用在遭遇 XSS 等攻击时被完全接管。然而现实中仍有大量合法场景需要动态求值能力典型代表包括基于字符串拼装 HTML 片段并写入文档使用 Handlebars、Underscore、EJS 等依赖new Function()编译模板的模板引擎运行第三方 JS 库如某些混淆代码、计算器引擎时其内部依赖eval。示例文档明确指出由于默认 CSP 禁止这些能力使用沙箱sandbox机制是该场景下的必要手段。沙箱的职责是把不安全的代码关进笼子里而不是放宽整个应用的安全策略——这正是沙箱化内容设计的核心思想。示例总览一个最简单的沙箱演示_archive/apps/samples/sandboxed-content示例构建了一个包含主窗口和沙箱化 iframe 的应用主窗口main.html显示 Main Window声明自己不是沙箱化的主窗口内嵌一个 380×140 的 iframe加载沙箱化页面sandboxed.html沙箱化页面内通过eval()执行一段内联脚本向自己的#message容器写入 HTML 文本。该示例触及的 API 只有 Runtime应用启动生命周期是最小可运行的沙箱演示。运行时界面见示例的截图 assets/screenshot_1280_800.png。核心配置清单文件中的sandbox字段沙箱机制的开关完全由应用的清单文件manifest.json控制。示例的 manifest.json 内容如下{ name: Sandboxed Content Sample, version: 1.0.2, manifest_version: 2, minimum_chrome_version: 23, app: { background: { scripts: [main.js] } }, icons: { 128: icon_128.png }, sandbox: { pages: [sandboxed.html] } }关键点字段值说明manifest_version2打包应用时代的清单版本MV2minimum_chrome_version23沙箱化页面能力自 Chrome 23 起可用app.background.scripts[main.js]应用后台脚本负责创建窗口sandbox.pages[sandboxed.html]声明哪些页面被放入沙箱被声明的页面将不再受应用默认 CSP 约束允许使用eval()等动态执行能力关键语义sandbox.pages中列出的每个页面都会被加载到带唯一随机来源unique origin的沙箱化 iframe 中。沙箱页面拥有相对宽松的 CSP允许脚本与eval但付出的代价是无法直接访问chrome.*API如chrome.app.*、chrome.runtime.*不能访问 DOM 存储localStorage、sessionStorage等需要权限的资源与主页面之间只能通过受限的消息通道交互见下文通信范式一节。一个典型误区是在sandbox.pages中同时列出主页面这没有必要也不正确——沙箱只应包裹那些确实需要动态求值的页面。在示例中只有sandboxed.html需要eval因此只有它被列入沙箱。应用启动流程与窗口创建应用入口是清单中声明的后台脚本 main.js它通过 Runtime API 监听启动事件并创建主窗口chrome.app.runtime.onLaunched.addListener(function() { chrome.app.window.create(main.html, { id: mainwin, innerBounds: {width: 400, height: 350} }); });chrome.app.runtime.onLaunched应用被用户启动时触发对应文档中列出的 Runtime APIchrome.app.window.create创建应用窗口加载main.html作为窗口内容innerBounds: {width: 400, height: 350}指定窗口初始尺寸配合主窗口内 iframe 的width380 height140两者基本吻合保证沙箱内容完整可见。沙箱化页面eval 在这里被允许沙箱化页面 sandboxed.html 的核心是一个调用eval()的内联脚本body h1Sandboxed Content/h1 pI am the sandboxed iframe./p div idmessage/div script eval(document.getElementById(\message\).innerHTML \pI am the output of an eval-ed inline script./p\); /script /body在普通的打包应用中这段内联脚本会直接违反默认 CSP 而被拒绝执行正是因为该页面被列入了sandbox.pages浏览器才允许其运行。执行后#message容器内会插入一段p文本页面标题下方出现 I am the output of an eval-ed inline script. 一行内容。注意沙箱化 iframe 本身没有沙箱 HTML 属性sandbox限制——它只是通过 manifest 声明获得的沙箱化页面身份而不是 HTML5 原生 iframe sandbox 特性两者不要混淆。进阶实战沙箱内运行 Handlebars 模板引擎并通过 postMessage 协作仅靠eval拼字符串只是入门。仓库中同目录下的姊妹示例 sandboxSandboxed Frame Sample展示了沙箱机制的完整实战价值在沙箱化 iframe 中加载 Handlebars 模板库由主页面通过postMessage传入数据沙箱页面完成模板编译与渲染后把结果回传主页面。该示例的 manifest.json 将sandbox.html声明为沙箱页面sandbox: { pages: [sandbox.html] }沙箱页面预编译模板并监听消息沙箱页面 sandbox.html 中通过script srchandlebars-1.0.0.beta.6.js引入 Handlebars 模板库。Handlebars 编译模板时依赖new Function()动态生成渲染函数这正是它必须运行在沙箱内的原因页面加载时用Handlebars.compile(source)将两个text/x-handlebars-template脚本块预编译为模板函数templates[name] Handlebars.compile(source);注册window.addEventListener(message, ...)监听来自外层框架的消息根据event.data.templateName选取模板、以event.data.context为数据调用模板渲染并通过event.source.postMessage({result: result}, event.origin)把结果回传调用方若模板名未知则返回Unknown template: ...错误信息。主页面postMessage 请求与结果接收主页面 mainpage.html 内嵌一个隐藏的 iframestyledisplay: none;来承载沙箱其逻辑在 mainpage.js 中document.getElementById(sendMessage).addEventListener(click, function(event) { counter; var message { command: render, templateName: sample-template- counter, context: {counter: counter} }; document.getElementById(theFrame).contentWindow.postMessage(message, *); }); // on result from sandboxed frame: window.addEventListener(message, function(event) { document.querySelector(#result).innerHTML event.data.result || invalid result });工作流程为点击按钮 → 计数器自增 → 主页面通过contentWindow.postMessage(message, *)向沙箱 iframe 发送{command, templateName, context}→ 沙箱页面用{{counter}}占位符渲染出 Hello / Welcome back 模板 → 结果回传 → 主页面将渲染后的 HTML 写入#result。两个模板分别对应奇数/偶数计数直观演示了同一沙箱服务多个模板的能力。通信范式的通用要点从两个示例可以提炼出沙箱化页面的协作范式单向能力隔离所有不安全的动态求值eval、模板编译都收敛在沙箱页面内部完成消息驱动主页面→沙箱用contentWindow.postMessage沙箱→主页面用event.source.postMessage入参出参皆为纯数据context只携带可序列化数据沙箱结果同样以字符串/数据形式返回主页面只负责 DOM 写入不接触不安全代码示例中使用postMessage(message, *)属于简化演示写法生产环境应指定明确的 targetOrigin并在沙箱侧校验event.origin。何时使用沙箱、注意事项与限制适用场景需要在内置页面中使用eval()/new Function()典型如模板引擎Handlebars、Underscore、EJS、运行时动态编译、第三方依赖eval的库等。限制清单从源码结构与 manifest 声明可以确认沙箱页面无法访问chrome.*扩展/应用 API无法直接使用localStorage等存储能力必须由主窗口通过消息中继沙箱页面的唯一随机来源意味着它与应用其他部分天然隔离不能直接共享 DOM 或 JavaScript 作用域只有被列入sandbox.pages的页面才获得宽松 CSP未被列入的页面仍受默认 CSP 严格约束绝不能把整个应用页面全部声明为沙箱否则会失去 CSP 防护意义该机制适用于 Manifest V2 时代的打包应用示例manifest_version为 2Chrome 23 可用MV3 扩展已无内置页面沙箱字段属于历史归档用法本文所有路径位于仓库_archive归档目录仅供学习参考。总结sandboxed-content示例用最小代码量演示了打包应用沙箱机制的完整链路manifest.json的sandbox.pages声明 → 主窗口嵌入沙箱化 iframe → 沙箱页面内自由使用eval()。而sandbox示例进一步展示了它的工业级用法在沙箱内运行依赖new Function()的 Handlebars 模板引擎并借助postMessage实现主页面与沙箱之间的安全数据交换。沙箱机制的本质是在不放松整个应用 CSP 的前提下为确实需要动态求值能力的代码开辟一个受控的隔离执行区——这是理解 Chrome 应用安全模型的重要一环。参考资源仓库内沙箱化内容示例README.md、manifest.json、sandboxed.html、main.js、main.htmlHandlebars 沙箱协作示例README.md、sandbox.html、mainpage.js、mainpage.html界面截屏sandboxed-content/assets/screenshot_1280_800.png、sandbox/assets/screenshot_1280_800.png赞分享示例工程【免费下载链接】chrome-extensions-samplesChrome Extensions Samples项目地址https://gitcode.com/gh_mirrors/ch/chrome-extensions-samples点击查看免费下载相关推荐在 Chrome 打包应用中使用 Dart以 chrome-extensions-samples 的 Dart 时钟应用为例在 Chrome 打包应用中使用 Dart以 chrome extensions samples 的 Dart 时钟应用为例 本篇技术指南以 chrome e示例工程在 Chrome 打包应用中运行 TCP 服务器解析 chrome-extensions-samples 的 Chrome Commando 示例在 Chrome 打包应用中运行 TCP 服务器解析 chrome extensions samples 的 Chrome Commando 示例 导读 本篇示例工程Chrome 扩展 MV3 沙箱机制实战基于 chrome-extensions-samples 在 sandbox.html 中安全运行 Handlebars 模板Chrome 扩展 MV3 沙箱机制实战基于 chrome extensions samples 在 sandbox.html 中安全运行 Handlebar示例工程上一篇10分钟上手curlconverter从命令行到代码的无缝转换下一篇嵌入式系统静态分析从0到1构建代码安全审计体系创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考