Flux Art先判断是否真的需要一个可交互文档
Flux Art 素材进入自建审核台后，有些团队用 iframe 展示合作方提供的预览页面。如果只需要看一张静态图，应先考虑图片形式，不要无意中把素材交付变成执行外部文档。确实需要嵌入交互预览时，再明确它必须具备哪些能力。本文讨论自建页面的隔离设计，不报告平台漏洞，也不承诺加一个 sandbox 属性便能解决所有内容风险。
从禁止开始列必要能力
建议先列出必须完成的动作，例如缩放展示或用户明确打开一个受控详情页，再逐项判断需要的能力。脚本执行、表单提交、顶层导航和弹出窗口不是同一许可。不要因为一个按钮不起作用就复制其他项目的完整许可列表。预览是否需要账户、存储和同源访问，也应有业务理由；若需要大量高权限交互，考虑改成单独受控应用，而不是持续扩大审核台的嵌入权限。
理解脚本与同源身份组合的后果
MDN 的 iframe 文档说明 sandbox 的不同许可各有作用，并特别提醒：同源嵌入内容同时获得 allow-scripts 与 allow-same-origin 时，可能移除隔离限制。技术依据见 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe 。下面是假设权限核对表，不是真实渗透测试。不要把 allow-same-origin 理解成“只允许同源内容”，它涉及嵌入文档的源身份处理。
| 能力 | 先问的业务问题 | 验收证据 |
|---|---|---|
| 脚本 | 静态展示是否足够 | 必要交互与禁止动作 |
| 源身份 | 为何需要原源身份 | 与父页面关系审查 |
| 表单 | 预览是否需要提交 | 未批准提交仍受限 |
| 导航 | 是否允许离开审核页 | 目标与用户动作 |
| 新窗口 | 是否确有外部打开需求 | 新上下文限制说明 |
| 未知能力 | 是否有明确负责人 | 待补证不放行 |
把不可信内容与业务会话分开
如果预览文档与工作台共享源和凭据，嵌入限制配置错误可能扩大影响。建议在设计阶段评估独立来源、最少凭据和不向预览传递主业务令牌的方案，再由安全负责人确认具体实现。分开来源并不自动证明所有风险消失，消息回传、文件访问和下载仍需检查。这里的建议是架构审查项，不要求读者直接修改现有域名、账户权限或生产部署。
新窗口不是原框架的延伸保证
用户可能通过预览里的链接或按钮离开框架。应明确是否允许弹窗、导航和在新页面打开内容，以及新上下文还保留哪些限制。不要只检查嵌入状态下按钮无法操作，就认为同一文档单独打开也受相同保护。对于不需要跳转的纯审核任务，保留更小能力集合；确有外部跳转需求时，单独定义目标、用户确认和返回路径，不能用一组宽松参数同时满足所有场景。
分开检查能做和不能做的动作
假设一个隔离预览只需要显示替代商品图片，不需要提交表单、改变父页面或自动打开新窗口。这是假设验收输入，不是真实客户素材。先验证展示和必要交互，再测试约定禁止的动作仍不可用。随后把同一文档放到不同源、重新载入和单独打开，记录行为差异。测试只在自己控制的页面进行，不以此尝试访问其他人的页面数据或绕过其保护。
业务失败时保留隔离，不靠放开权限救场
预览按钮不可用可能是设计与许可不匹配，也可能是页面脚本、网络或身份问题。先定位失败动作与所需能力，再判断是否有不增加权限的替代流程，例如下载已批准的静态预览或由用户在独立应用中处理。未知原因写待补证。不要把移除整个 sandbox 作为临时修复上线，更不能在没有审查的情况下同时增加脚本、源身份、弹窗与导航权限。
审查配置必须绑定具体预览版本
建议保存父页面实际 iframe 属性、嵌入来源、预览文档版本、必要能力说明和负向用例结果。预览供应方换了脚本或登录机制后，旧记录不能继续代表新版本。若发现超出约定的动作，暂停该入口并保留证据，由维护者评估修复范围；不在公共故障截图中暴露客户页面或令牌。隔离验收只是应用安全的一部分，不能替代服务端授权和内容权利审核。
让审核员知道这是预览，不是信任证明
技术依据核对于2026年11月10日，本文没有执行实际权限修改或完整安全审计。交付给审核员的说明应写清可用动作、受限动作和异常反馈入口。Flux Art 的创作入口见 https://flux-art.net/zh ，自建工作台接入可参考 https://flux-art.net/zh/openapi 。生成内容能用于商业用途，输入素材权利与商品真实性仍须核验；页面被成功嵌入也不代表内容已经获得授权。