[fix]: Add support for TrustedTypes in Svelte

[fallaciousreasoning]

Before submitting the PR, please make sure you do the following

Resolves #14438
Resolves #10826

This PR makes it possible to use Svelte on pages which require TrustedTypes support via their CSP by wrapping assignments to innerHTML in a TrustedTypePolicy called svelte-trusted-html if the TrustedTypes API exists.

Servers can allowlist the policy by setting require-trusted-types-for 'script'; trusted-types svelte-trusted-html in their Content-Security-Policy header.

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

Note: I haven't run the tests since I don't have pnpm setup properly.

I have tested that:

1. A project with a CSP fails with Tip of Tree Svelte
2. That project works when installing this revision of Svelte
3. The project (with this revision) works in Browsers with no TrustedTypes support (i.e. Firefox, Safari)

• Run the tests with pnpm test and lint the project with pnpm lint

My test project is here: https://github.com/fallaciousreasoning/svelte-tt-test/blob/master/src/routes/%2Bpage.server.js

The only changes to the default project is adding the CSP in src/routes/page.server.js

[changeset-bot]

🦋 Changeset detected

Latest commit: 0be07ca

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-16271-svelte.vercel.app/

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@16271

[7nik]

Btw, I think configuring CSP should be added to the docs. Or adding trusted-types svelte-trusted-html integrated to SvelteKit.

[Rich-Harris]

Thank you, but I don't think this is the right fix — it's saying that all HTML is trusted regardless of its provenance, which is the opposite of the intent of TrustedTypes.

What if {@html ...} accepted either a string or an instance of TrustedHTML? That way people can define their own policies with their own sanitization logic. It becomes slightly more cumbersome to use component libraries that inject HTML — those libraries would need to either also accept TrustedHTML or a function that created TrustedHTML given some input — but that's a feature rather than a bug.

[Rich-Harris]

(admittedly not sure how to support SVG and MathML in this case; might not be possible. Perhaps that's just the cost of CSP support though, to be borne by apps that need CSP support)

[dummdidumm]

I agree that this shouldn't affect {@html ...}, but it's also needed for all of our internal template generation which is known to be safe. So if we can adjust it so that {@html ...} does not use the svelte-html trusted types then this should be a good addition.

[7nik]

@html and bind:innerHTML can use a separate policy name. Or implement #15528, so users can sanitize and trustify html in it.

Another CSP thing is that require-trusted-types-for 'script' breaks dynamic creation of scripts:

{#if condition}
  <div>
    <script>console.log("inline")</script>
    <script src="/static/my-script.js"></script>
  </div>
{/if}

[fallaciousreasoning]

Thank you, but I don't think this is the right fix — it's saying that all HTML is trusted regardless of its provenance, which is the opposite of the intent of TrustedTypes.

I think its okay to trust the output of Svelte's internal template generation - its what the other Frameworks do (i.e. Polymer/Lit). I'll try and work out how to carve out {@html ...} 😄

@html and bind:innerHTML can use a separate policy name. Or implement #15528, so users can sanitize and trustify html in it.

@7nik - I think I'll try and get it working with a separate policy for now Actually, thinking about this, its untrusted so it should go through the default policy - the ideal would be if users could do:

{@html customPolicy.createHTML('<span>Hello</span>')}

but I'm not going to dig into that here.

Another CSP thing is that require-trusted-types-for 'script' breaks dynamic creation of scripts:

I think you should be able to allow dynamic script creation via some of the other policies (i.e. unsafe-inline or whitelisting the script URL). Either way, I'd prefer it to be tackled separately.

[fallaciousreasoning]

Okay, @html doesn't go through policy now. I tested and bind:innerHTML already wasn't going through the policy so that should be fine.

FWIW, I think this a pretty useful improvement as is because it means that apps which don't use bind:innerHTML and @html will be able to use Svelte with require-trusted-types-for 'script' now.

I think the ideal solution for @html and bind:innerHTML would be to allow authors to pass in TrustedHTML rather than creating a custom policy for them (which would throw an error if we try to register it and it isn't supported).