首页 URL iframe 缺少 allow-same-origin 导致被嵌页面自定义字体失效（rc.16 回归）

[Heykode]

提交前必读（请勿删除本节）

• 文档：https://docs.newapi.ai/
• 使用问题先看或先问：https://deepwiki.com/QuantumNous/new-api
• 开启透传后的转发相关反馈不接受 issue；透传模式会直接转发请求，请自行确认上游行为。
• 不接受 coding plan、逆向渠道等技术支持类 issue。
• 警告：删除本模板、删除小节标题或随意清空内容的 issue，可能会被直接关闭；重复恶意提交者可能会被 block。

您当前的 newapi 版本

v1.0.0-rc.16（回归引入版本；v1.0.0-rc.15 及更早正常）

提交确认

• 非重复 issue: 我已搜索现有 Issues，确认目前没有类似 issue。
• 提交前必读: 我已完整阅读上方"提交前必读"，并确认这不是使用、配置或接入类问题。
• 模板完整: 我未删除此模板中的任何引导内容或小节标题，并会按要求完整填写。
• 维护成本: 我理解项目维护者精力有限，不遵循模板要求的 issue 可能会被无视或直接关闭。

问题描述

当"首页内容（HomePageContent）"设置为一个 URL 时，首页会用 <iframe> 嵌入该 URL。从 v1.0.0-rc.16 开始，被嵌入页面内通过 @font-face（woff2）加载的自定义字体全部失效，回退为系统默认字体；而直接在浏览器打开同一个 URL 时字体显示正常。rc.15 及更早版本在 iframe 内字体正常。

根因分析

web/default/src/features/home/index.tsx:54 的 URL iframe 带了 sandbox 属性，但缺少 allow-same-origin：

sandbox='allow-forms allow-popups allow-popups-to-escape-sandbox allow-scripts'

缺少 allow-same-origin 时，被嵌文档被浏览器放入唯一 opaque origin（null），即使它加载的是自己同域的资源。而 CSS @font-face 请求字体在浏览器中始终以 CORS 模式发起：正常同源时 origin 匹配直接放行，但现在文档 origin 变成 null，字体请求携带 Origin: null，被嵌页面服务器通常不会为自家静态字体返回 Access-Control-Allow-Origin，于是字体请求被 CORS 拦截 → 回退系统字体。这也解释了为何只有字体受影响、图片等非 CORS 强约束资源正常。

该 sandbox 属性由 commit 0b48ad86（fix(web): render custom HTML and Markdown content consistently (#5760)，2026-06-27）在一次"统一 HTML/Markdown 渲染"的重构中随附引入，commit message 未说明为何要给 URL iframe 加 sandbox。git tag --contains 0b48ad86 仅包含 v1.0.0-rc.16；rc.13/14/15 的该 iframe 均无 sandbox 属性，与"rc.15 正常、rc.16 异常"的现象一致。

复现步骤

1. 管理层设置 → 首页内容（HomePageContent）填入一个使用了 @font-face 自定义字体的 URL（例如自建营销/落地页）。
2. 用无痕窗口访问 new-api 首页，首页以 iframe 加载该 URL。
3. 观察被嵌页面字体：rc.16 下回退为系统字体；直接打开该 URL 则字体正常。
4. 开发者工具 Network 面板可见 woff2 请求因 sandbox 的 opaque origin 触发跨域被拦截。

预期结果

被嵌页面在 iframe 内应与直接打开时字体表现一致（自定义 @font-face 字体正常加载）。

建议修复

首页内容 URL 由管理员配置（可信来源），在 features/home/index.tsx:54 的 sandbox 值中补上 allow-same-origin 即可恢复被嵌页面真实 origin，同源字体/CSS 恢复正常：

sandbox='allow-same-origin allow-forms allow-popups allow-popups-to-escape-sandbox allow-scripts'

安全权衡：allow-same-origin + allow-scripts 组合下，被嵌页面脚本理论上可移除自身 sandbox 并以真实 origin 访问同域存储；鉴于该 URL 为管理员配置的可信内容，此组合通常可接受。我将另提 PR 关联本 issue。

相关截图

（如维护者需要，可补充 Network 面板 woff2 跨域拦截截图）

---

补充说明：本 issue 的代码定位与分析在 AI 辅助下完成，结论均经源码与 git 历史核对。

[new-api-reviewer-bot]

[Bot Review]

感谢提交，模板信息完整，版本、提交确认、问题描述和复现步骤都已填写。我没有在当前开放 issue 列表中看到明显重复；#5900 同样提到 rc.16 前端展示相关现象，但描述对象不同，暂不按重复处理。

[Heykode]

补充：同一个 sandbox 属性缺失还引发第二个症状，根因同源，已一并纳入 PR #5909。

症状二：被嵌页面 target="_top" 菜单链接在桌面点击无跳转

• 现象：被嵌页面的导航/菜单链接普遍使用 target="_top"（意图跳出 iframe、导航顶层窗口）。桌面浏览器点击这些链接静默无反应；部分移动端浏览器表现为可跳转。
• 根因：features/home/index.tsx 的 iframe sandbox 缺少 allow-top-navigation-by-user-activation（也无 allow-top-navigation），默认 sandbox 禁止顶层导航。桌面 Chrome/Edge 严格执行该限制导致 _top 被拦，部分移动端执行较宽松故"能跳"，形成"手机能跳、电脑不跳"的差异。
• 与字体问题同属 fix(web): render custom HTML and Markdown content consistently #5760（commit 0b48ad86）引入的 sandbox token 不完整问题，rc.15 及更早无 sandbox 故无此限制。

PR #5909 现补全两个 token：allow-same-origin（修字体）+ allow-top-navigation-by-user-activation（修 _top 跳转，采用 user-activation 变体以最小授权）。

说明：分析在 AI 辅助下完成，结论经源码与 git 历史核对。