flawopen.com/XSS in JavaScript/Svelte
Is Svelte safe from XSS by default?
Think of `{comment}` as printing a note: angle brackets stay visible as text. `{@html comment}` is like asking the typesetter to treat the page's marks as layout instructions. If those marks come from an untrusted source, the browser may interpret them as HTML and create XSS.
<p>{@html comment}</p>
// comment is parsed as real markup
<p>{comment}</p>
// escaped automatically
The rule
Svelte compiles ordinary {expression} output as escaped text, so a value is not interpreted as HTML markup. By contrast, {@html} intentionally renders an HTML string; the Svelte docs warn that the value must be escaped or controlled to prevent XSS. Treat it as a security-sensitive HTML sink, and use a maintained sanitizer when user-authored rich text is required.
How to check your codebase
Search `.svelte` files for `{@html}`. For each match, trace the value to its origin and every transformation. Treat user input, external data, and stored user content as untrusted. If the content should be text, use `{expression}`. If rich HTML is required, sanitize it with a maintained HTML sanitizer and test that disallowed markup is removed.
grep -rn "{@html" --include="*.svelte" .Rich HTML: preserve the sanitization boundary
Use `{expression}` when content should appear as text. If readers must author HTML, sanitize the final content with a maintained HTML sanitizer such as DOMPurify before passing it to `{@html}`. Do not concatenate or mutate the sanitized result afterward; that can invalidate the protection. Keep the sanitizer patched and allow only the markup elements and attributes the product needs. HTML sanitization does not make the same value safe in JavaScript, CSS, or URL contexts.
References
- Svelte docs — {@html ...}
- flawopen.com — XSS in JavaScript
- DOMPurify — project documentation
- OWASP — Cross Site Scripting Prevention