Svelte 5.52.0 为 {@html} 增加 TrustedHTML 支持，实现更安全的 Trusted Types 集成

Svelte 5.52.0（于 2026 年 2 月 18 日发布）为 {@html} 块引入对 TrustedHTML 对象的原生支持：Svelte 将接受并保留 TrustedHTML 值，而不是强制将其转换为字符串，从而更容易采用浏览器的 Trusted Types API，并在呈现原始 HTML 时降低 XSS 风险。 (github.com)

为什么这对全栈团队很重要

• Trusted Types 是浏览器级别的防御机制，通过要求接收 HTML 的 sinks（如 innerHTML）接收由已批准策略创建的值，来防止 DOM XSS。框架级别的支持意味着现在可以将 Svelte 的服务器/客户端流程无缝接入该模型，而不会让框架在后台把 TrustedHTML 对象悄然转换回不可信的字符串，从而消除一类意外回归的问题。 (github.com)
• 对于 SSR + hydration 应用，这减少了服务器渲染的标记与客户端策略互操作时的意外情况。使用 Content-Security-Policy: require-trusted-types-for 'script'（及相关策略）的团队，在有 Svelte 的情况下可以更实际地采用 Trusted Types。 (github.com)

实用且高影响力的升级清单

1. 升级到 [email protected]（或更高版本）。
2. 审查 {@html} 的使用：将任何现有的原始 HTML 接收点视为安全敏感，并在可行的情况下优先从已知安全来源产生 TrustedHTML 值。
3. 对于仅客户端的 Trusted Types：
   • 通过浏览器中的一个可信策略创建 HTML（policy.createHTML(...)），并将该 TrustedHTML 传递给渲染 {@html} 的组件。
   • 只有在本地测试完成后，才在生产环境中启用 CSP Trusted Types 策略。
4. 对于 SSR 场景：
   • 首选在服务端生成已清洗的字符串（如 DOMPurify），在首次客户端激活时通过浏览器策略将其转换为 TrustedHTML，然后再进行后续的 DOM 操作——这样服务端输出保持安全，同时仍与客户端的 Trusted Types 互操作。
   • 或者，使用安全序列化模式，让客户端代码在 hydration 阶段通过一个白名单策略来重构 TrustedHTML。
5. 彻底测试：在 staging CSP 中启用 require-trusted-types-for，以暴露仍在使用未受信任字符串的任何位置。

迁移陷阱与指南

• TrustedHTML 是一个在浏览器运行时的对象；服务器不能直接创建浏览器的 TrustedHTML 实例。该版本避免了强制转换，但不会自动把服务器创建的字符串变成 TrustedHTML——你的应用必须在客户端创建 TrustedHTML（或在 hydration 期间使用显式、审计过的序列化 → policy.createHTML 流程）。
• 不要依赖框架的强制转换来净化内容。TrustedHTML 的支持降低了采用 Trusted Types 的难度，但对于来自用户或第三方的任何内容，你仍然需要合理的净化和显式的信任模型。 (github.com)

结论 此次 Svelte 版本是一个实用且贴近实操的改进，帮助团队在加强网页应用对抗 XSS 时减少框架层面的障碍，使采用浏览器原生的防御措施更为直接——对于同时 SSR 与 hydration 复杂标记的全栈应用尤为重要。将此视为一个机会，审计 {@html} 的使用，采用或加强净化策略，并在生产环境启用严格 CSP 之前，在 staging 中进行分阶段发布 Trusted Types。 (github.com)

来源：

来源

• 来源