🦋 Changeset detected

Latest commit:0be07ca

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

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

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

Playground

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

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

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 ofTrustedTypes.

What if{@html ...} accepted either a string or an instance ofTrustedHTML? 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 acceptTrustedHTML or a function thatcreatedTrustedHTML given some input — but that's a feature rather than a bug.

(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)

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.

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

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

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

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:

{@htmlcustomPolicy.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.

Okay,@html doesn't go throughpolicy now. I tested andbind: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 usebind:innerHTML and@html will be able to use Svelte withrequire-trusted-types-for 'script' now.

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

What about usingtrustedTypes?.isHTML(html) to check if the passed value isTrustedHTML?

Offtop: it's funny thatwindow.trustedTypes is protected from writing, buttrustedTypes.isHTML = () => true andTrustedTypePolicyFactory.prototype.isHTML = () => true; are still allowed 😄

What about using trustedTypes?.isHTML(html) to check if the passed value is TrustedHTML?

You mean to be able to set{@html ...} to TrustedHTML? Yeah, that's probably a good approach - tbh, I didn't really dig into why it wasn't working, and maybe we won't even need to check 😆

Just wondering if the Svelte team would consider merging without it? This PR fixes Svelte for our use case (so we don't need to create a default policy).

Offtop: it's funny that window.trustedTypes is protected from writing, but trustedTypes.isHTML = () => true and TrustedTypePolicyFactory.prototype.isHTML = () => true; are still allowed

Huh, that is kind of weird - I guess it'll still fail when you try and assign a sink to the non-trusted HTML though.

Look at

Okay, I think something like

var html = trustedTypes.isTrusted(value) ? value : (value + '') should work for the non-SVG / non-MATH elements - before going and changing that, just want to confirm with@dummdidumm that this is something Svelte would consider merging.

I think this should allow creating fragments with the desired namespace without losing trustiness:

exportfunctioncreate_fragment_from_html(html,untrusted=false,namespace=null){vartemplate=document.createElement('template');if(namespace){varcontainer=namespace=='svg'                ?document.createElementNS(NAMESPACE_SVG,'svg')                :document.createElementNS(NAMESPACE_MATHML,'mathml');container.innerHTML=untrusted ?html :create_trusted_html(html.replaceAll('<!>','<!---->'));template.append(...container.childNodes);}else{template.innerHTML=untrusted ?html :create_trusted_html(html.replaceAll('<!>','<!---->'));}returntemplate.content;}

plus a bit simplifieshtml() function