Svelte 5.52.0 adds TrustedHTML support for {@html}, enabling safer Trusted Types integration

Svelte 5.52.0 (published Feb 18, 2026) introduces first-class support for TrustedHTML objects in {@html} blocks: Svelte will accept and preserve TrustedHTML values instead of coercing them to strings, making it easier to adopt browser Trusted Types APIs and reduce XSS risk when rendering raw HTML. (github.com)

Why this matters for full-stack teams

• Trusted Types are a browser‑level defensive mechanism that prevents DOM XSS by requiring that sinks which accept HTML (like innerHTML) receive values created by an approved policy. Framework-level support means you can now wire Svelte's server/client flow into that model without having the framework silently convert a TrustedHTML object back into an untrusted string—removing a class of accidental regressions. (github.com)
• For SSR + hydration apps, this reduces surprises where server-rendered markup and client-side policies interact. Teams using Content-Security-Policy: require-trusted-types-for 'script' (and related policies) can adopt Trusted Types more practically with Svelte in place. (github.com)

Practical, high-impact upgrade checklist

1. Upgrade to [email protected] (or later).
2. Audit uses of {@html}: treat any existing raw-HTML sinks as security-sensitive and prefer producing TrustedHTML values from known-safe sources where feasible.
3. For client-only Trusted Types:
   • Create HTML via a trusted policy in the browser (policy.createHTML(...)) and pass that TrustedHTML to components that render {@html}.
   • Enable CSP Trusted Types policies in production only after testing locally.
4. For SSR scenarios:
   • Prefer producing sanitized strings server-side (e.g., DOMPurify) and, on first client activation, convert to TrustedHTML via a browser policy before further DOM operations—so server output remains safe while still interoperating with client Trusted Types.
   • Alternatively, use safe serialization patterns and have client-side code reconstruct TrustedHTML through an allowlisted policy during hydration.
5. Test thoroughly: enable require-trusted-types-for in staging CSP to surface any places where untrusted strings are still used.

Migration pitfalls and guidance

• TrustedHTML is a browser runtime object; servers cannot create a browser TrustedHTML instance directly. The release avoids coercion, but it does not magically make server-created strings automatically TrustedHTML on the client—your app must create TrustedHTML client-side (or use an explicit, audited serialization → policy.createHTML flow during hydration).
• Do not rely on framework coercion to sanitize content. TrustedHTML support reduces friction for adopting Trusted Types, but you still need sane sanitization and an explicit trust model for any content from users or third parties. (github.com)

Bottom line This Svelte release is a practical, ground-level improvement for teams hardening web apps against XSS: it removes a framework-level impedance mismatch with Trusted Types and makes adopting browser-native defenses more straightforward—especially important for full‑stack apps that SSR and hydrate complex markup. Treat this as an opportunity to audit {@html} usage, adopt or tighten sanitization policies, and plan a staged rollout of Trusted Types in staging before enabling strict CSP in production. (github.com)

Source:

Source

• Source