为什么 playground-elements 默认把沙箱放在 unpkg.com读懂 4 条关键安全规则【免费下载链接】playground-elementsServerless coding environments for the web.项目地址: https://gitcode.com/gh_mirrors/pl/playground-elementsplayground-elements 是一套运行在浏览器里的无后端代码沙箱编辑器Serverless coding environments for the web它默认把沙箱执行环境放在 unpkg.com 上。本文带你读懂这一设计背后的 4 条关键安全规则让你安全地自定义sandboxBaseUrl而不踩坑。先搞懂Playground 的沙箱到底在做什么Playground 最大的特点是代码 100% 在浏览器里运行不经过任何后端服务器。它的工作原理是通过Service Worker拦截某个 URL 空间的请求用你本地项目文件伪造 HTTP 响应相当于在浏览器里虚拟出一个网站预览组件里的iframe指向这个虚拟 URL 的index.html你在编辑器里改的代码就实时跑在这个 iframe 里。也就是说预览 iframe 里跑的任意 JavaScript权限等同于该 URL 所在源origin的权限。如果 iframe 和你的站点同域恶意代码就能通过window.parent篡改你的页面、读取你的 Cookie。这就是为什么沙箱跑在哪个域名下是 Playground 最核心的安全决策。为什么默认选 unpkg.com在 src/playground-project.ts 中可以看到默认值sandboxBaseUrl https://unpkg.com/playground-elements${npmVersion}/选 unpkg.com 有三个恰好完美的理由天然无权限unpkg.com 是一个公共 CDN你的用户在这里没有任何登录态、Cookie 或敏感数据恶意代码偷无可偷版本自动对齐unpkg 按 npm 版本号托管包文件沙箱所需的 Service Worker 文件与页面加载的组件永远同版本不会因版本错配而出错当前版本号由 src/shared/version.ts 自动生成默认跨站cross-site对绝大多数站点来说unpkg.com 与你处于不同顶级域浏览器更容易为预览 iframe 分配独立进程用户写死循环也不会卡死你的主页面。另外注意Playground 还默认用 unpkg.com 解析import lit这类裸模块导入除非你设置cdnBaseUrl见 src/typescript-worker/worker-context.ts。4 条关键安全规则改沙箱地址前必读官方文档明确警告⚠️ 随意修改沙箱地址可能给你的站点引入安全漏洞。如果你要自定义sandbox-base-url新地址必须同时满足以下 4 条规则详见 README.md 的 Sandbox security 章节规则 1必须与宿主页「不同源」沙箱源必须和承载 Playground 组件的页面源不同否则不信任的代码可以通过window.parent直接篡改父窗口比如把登录链接换成钓鱼地址。官方还建议更进一步使用完全不同的 site不同顶级域或通过Origin-Agent-Cluster响应头实现进程隔离。规则 2不能访问任何敏感 Cookie沙箱源上不能存在用户的认证 Token、会话 Cookie 等。否则恶意代码可以把它们读走并转发到攻击者服务器。规则 3不能访问敏感资源与 API无论是通过同源策略还是通过你配置过的 CORS 头授予的跨域访问权沙箱源都不能够调用change_password、get_credit_card之类的接口。简单说这个源上不能挂任何值钱的接口。规则 4必须托管同版本的 2 个沙箱文件新地址必须从 playground-elements 包中提供以下 2 个预压缩文件且版本必须与你导入的组件完全一致playground-service-worker.jsplayground-service-worker-proxy.htmlService Worker 负责接管虚拟 URL 空间的请求而代理页面则负责在服务 Worker 重启后重新建立会话其源码见 src/service-worker/playground-service-worker.ts。版本不一致会导致文件协议不匹配预览直接失效。进阶为什么浏览器会为沙箱开独立进程浏览器如 Chrome只为「不同 site」的 iframe 分配独立进程。origin 由协议子域顶级域端口决定而 site 只看协议顶级域example.com与foo.example.com是不同源但同站example.com与example.net才是不同站。如果沙箱与主站同站可以在服务端对所有响应加Origin-Agent-Cluster: ?1头来强制进程隔离——Playground 的 Service Worker 返回项目文件时已经自动加了这个头见 src/service-worker/playground-service-worker.ts但你自己服务器上的其他响应也要加上。什么时候才需要改掉默认的 unpkg.com只在两种场景下建议覆盖sandboxBaseUrl不想依赖 unpkg.com 的可用性它故障时预览会受影响内网环境无法访问公网 CDN。替换时别忘了如果不设sandboxBaseUrl也要同时设置cdnBaseUrl如https://cdn.jsdelivr.net/npm来消除对 unpkg 的模块解析依赖否则只堵住了一条路。这两个属性在 src/playground-ide.ts 和 src/playground-project.ts 中都可以通过 HTML 属性sandbox-base-url/cdn-base-url直接声明。总结要点说明默认沙箱https://unpkg.com/playground-elements版本/天然无权限、版本自动对齐规则 1与宿主页不同源防止window.parent攻击规则 2沙箱源上不能有敏感 Cookie规则 3沙箱源不能访问敏感 API / 资源规则 4同版本托管 Service Worker 与代理页面 2 个文件默认值就是安全值。理解这 4 条规则后无论是否自定义沙箱地址你都能自信地向用户保证Playground 里的任何代码都跑不出笼子。️【免费下载链接】playground-elementsServerless coding environments for the web.项目地址: https://gitcode.com/gh_mirrors/pl/playground-elements创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
为什么 playground-elements 默认把沙箱放在 unpkg.com读懂 4 条关键安全规则【免费下载链接】playground-elementsServerless coding environments for the web.项目地址: https://gitcode.com/gh_mirrors/pl/playground-elementsplayground-elements 是一套运行在浏览器里的无后端代码沙箱编辑器Serverless coding environments for the web它默认把沙箱执行环境放在 unpkg.com 上。本文带你读懂这一设计背后的 4 条关键安全规则让你安全地自定义sandboxBaseUrl而不踩坑。先搞懂Playground 的沙箱到底在做什么Playground 最大的特点是代码 100% 在浏览器里运行不经过任何后端服务器。它的工作原理是通过Service Worker拦截某个 URL 空间的请求用你本地项目文件伪造 HTTP 响应相当于在浏览器里虚拟出一个网站预览组件里的iframe指向这个虚拟 URL 的index.html你在编辑器里改的代码就实时跑在这个 iframe 里。也就是说预览 iframe 里跑的任意 JavaScript权限等同于该 URL 所在源origin的权限。如果 iframe 和你的站点同域恶意代码就能通过window.parent篡改你的页面、读取你的 Cookie。这就是为什么沙箱跑在哪个域名下是 Playground 最核心的安全决策。为什么默认选 unpkg.com在 src/playground-project.ts 中可以看到默认值sandboxBaseUrl https://unpkg.com/playground-elements${npmVersion}/选 unpkg.com 有三个恰好完美的理由天然无权限unpkg.com 是一个公共 CDN你的用户在这里没有任何登录态、Cookie 或敏感数据恶意代码偷无可偷版本自动对齐unpkg 按 npm 版本号托管包文件沙箱所需的 Service Worker 文件与页面加载的组件永远同版本不会因版本错配而出错当前版本号由 src/shared/version.ts 自动生成默认跨站cross-site对绝大多数站点来说unpkg.com 与你处于不同顶级域浏览器更容易为预览 iframe 分配独立进程用户写死循环也不会卡死你的主页面。另外注意Playground 还默认用 unpkg.com 解析import lit这类裸模块导入除非你设置cdnBaseUrl见 src/typescript-worker/worker-context.ts。4 条关键安全规则改沙箱地址前必读官方文档明确警告⚠️ 随意修改沙箱地址可能给你的站点引入安全漏洞。如果你要自定义sandbox-base-url新地址必须同时满足以下 4 条规则详见 README.md 的 Sandbox security 章节规则 1必须与宿主页「不同源」沙箱源必须和承载 Playground 组件的页面源不同否则不信任的代码可以通过window.parent直接篡改父窗口比如把登录链接换成钓鱼地址。官方还建议更进一步使用完全不同的 site不同顶级域或通过Origin-Agent-Cluster响应头实现进程隔离。规则 2不能访问任何敏感 Cookie沙箱源上不能存在用户的认证 Token、会话 Cookie 等。否则恶意代码可以把它们读走并转发到攻击者服务器。规则 3不能访问敏感资源与 API无论是通过同源策略还是通过你配置过的 CORS 头授予的跨域访问权沙箱源都不能够调用change_password、get_credit_card之类的接口。简单说这个源上不能挂任何值钱的接口。规则 4必须托管同版本的 2 个沙箱文件新地址必须从 playground-elements 包中提供以下 2 个预压缩文件且版本必须与你导入的组件完全一致playground-service-worker.jsplayground-service-worker-proxy.htmlService Worker 负责接管虚拟 URL 空间的请求而代理页面则负责在服务 Worker 重启后重新建立会话其源码见 src/service-worker/playground-service-worker.ts。版本不一致会导致文件协议不匹配预览直接失效。进阶为什么浏览器会为沙箱开独立进程浏览器如 Chrome只为「不同 site」的 iframe 分配独立进程。origin 由协议子域顶级域端口决定而 site 只看协议顶级域example.com与foo.example.com是不同源但同站example.com与example.net才是不同站。如果沙箱与主站同站可以在服务端对所有响应加Origin-Agent-Cluster: ?1头来强制进程隔离——Playground 的 Service Worker 返回项目文件时已经自动加了这个头见 src/service-worker/playground-service-worker.ts但你自己服务器上的其他响应也要加上。什么时候才需要改掉默认的 unpkg.com只在两种场景下建议覆盖sandboxBaseUrl不想依赖 unpkg.com 的可用性它故障时预览会受影响内网环境无法访问公网 CDN。替换时别忘了如果不设sandboxBaseUrl也要同时设置cdnBaseUrl如https://cdn.jsdelivr.net/npm来消除对 unpkg 的模块解析依赖否则只堵住了一条路。这两个属性在 src/playground-ide.ts 和 src/playground-project.ts 中都可以通过 HTML 属性sandbox-base-url/cdn-base-url直接声明。总结要点说明默认沙箱https://unpkg.com/playground-elements版本/天然无权限、版本自动对齐规则 1与宿主页不同源防止window.parent攻击规则 2沙箱源上不能有敏感 Cookie规则 3沙箱源不能访问敏感 API / 资源规则 4同版本托管 Service Worker 与代理页面 2 个文件默认值就是安全值。理解这 4 条规则后无论是否自定义沙箱地址你都能自信地向用户保证Playground 里的任何代码都跑不出笼子。️【免费下载链接】playground-elementsServerless coding environments for the web.项目地址: https://gitcode.com/gh_mirrors/pl/playground-elements创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
