make it clearer that @html is dangerous

[ecstrema]

Describe the problem

We just started a hackaton for the weekend, and decided to use svelte. 2 out of 4 of us had never used it before, so I recommended going through the tutorial.

The first reaction was (translated) "Happy to see that they tell users how to setup for xss attacks at the 4th page of the tutorial"

Followed by "In react they make you write __dangerousInnerHTML to make it clear that it's a bad idea, but here they are almost selling it as 'look how simple it is'".

They were talking about the @html tag and its corresponding page in the tutorial.

Describe the proposed solution

the @html tag is a great feature, but with great powers...

I would take three steps:

1. Move the page to the end of the tutorial. Imo it has nothing to do in the introduction.
2. Issue an error when @html is used, with an option to disable it.
3. In svelte 4, deprecate @html for @dangerousInnerHtml or something alike.

Alternatives considered

EDIT: Bad alternative

add a sanitize option to @html blocks

<div>{@html:sanitize content}</div>

That would filter <script> tags and other "dangerous" elements.
That is probably too complex/dangerous to implement.

Importance

nice to have

[baseballyama]

I think it is the user's responsibility to decide if sanitization is necessary because Svelte cannot decide if it is unintentional code for XSS attackable code.

The tutorial already mentioned XSS, and considering realistic use cases, {@html} is useful,
so I think the current situation is ok for me.

Svelte doesn't perform any sanitization of the expression inside {@html ...} before it gets inserted into the DOM. In other words, if you use this feature it's critical that you manually escape HTML that comes from sources you don't trust, otherwise you risk exposing your users to XSS attacks.

I think below 2 implementation are almost same so I don't think {@html:sanitize} needed.

<div>{@html:sanitize content}</div>
<div>{content}</div>

Sorry for dissenting opinion. This is just my personal opinion.

[ecstrema]

Thank you for being honest. What about having it as one of the first pages in the tutorial? Don't you think it should move more to the end?

[ecstrema]

see #7254

[ecstrema]

I think below 2 implementation are almost same so I don't think {@html:sanitize} needed.

Yeah I don't like this solution either.

It could be possible to sanitize by removing the <script> tags only, though. But it would be complex and probably dangerous too.

[baseballyama]

I agree with you throughout about thinking process.

This is warning message of Vue.js.
This warning is more explicit than Svelte's tutorial.
Should we be more explicit about the dangers?

And regarding moving {@html} to the end of the tutorial.
I think important point is that user can be able to recognize the risks when they learn about {@html}.
(Tutorial order always should be frequency of use and understandability.)
Moving it to the end of the tutorial is just hiding this problem.

[ecstrema]

(Tutorial order always should be frequency of use and understandability.)

I don't think @html tags are particularly important to know first. Certainly not before reactive declarations and statements.

[baseballyama]

Indeed.
I need to wait for more opinions from maintainers and users.

[bluwy]

I don't think we should move the html tutorial to last. As @baseballyama pointed out, it's a common use case so it would make sense to present it earlier. I think the warning shown in the tutorial is enough, and I don't get the same sentiment of it encouraging XSS attacks.

[brunnerh]

One more thing to consider is that there is nothing "encouraging" the use of @html, because you write HTML directly as part of the component most of the time and can just insert whatever values you need using the regular, safe and concise { ... } syntax. You are generally not building HTML strings in JS like in the olden days and then inserting that, there is no reason to.

[ecstrema]

it's a common use case so it would make sense to present it earlier

What do you mean by "a common use case". I consider it as bad practice at least, dangerous at most.

[bluwy]

ah i meant as more of "a common question". Beginners who learn a new framework or new to web dev in general would probably ask the question of "how do i render a string of html?". It's dangerous yes, but we've warned the user in the tutorial.

[ecstrema]

I don't get the same sentiment of it encouraging XSS attacks.

It's not about encouraging XSS attacks, it's about preventing them. Nobody would ever want to provide XSS attacks.

I think of it this way:

1. Vue doesn't have it in the tutorial at all. You have to look at the docs specifically to find the information.
2. React hides it behind __dangerousInnerHTML, and it is of course not described in the tutorial. Again you have to look at the docs.
3. The only mention I could find for angular is on the security page. Where they say:

For the HTML to be interpreted, bind it to an HTML property such as innerHTML. But binding a value that an attacker might control into innerHTML normally causes an XSS vulnerability.

For this reason, every single [innerHtml] tag gets sanitized to remove potentially dangerous content. The only way to truly set innerHtml is to use ElementRef and set the innerHtml property.

4. Django: The funny thing about searching online for "django innerHtml" is that the first official django page that appears is the release notes for django 1.8.14.

5. Elm completely removed the innerHtml property because of xss attacks.

These are just a few examples, but I believe that setting innerHTML should be avoided whenever possible. And this starts by not teaching new users its existence right at the beginning of the tutorial.

[Prinzhorn]

I don't think we should move the html tutorial to last. As @baseballyama pointed out, it's a common use case so it would make sense to present it earlier.

Let's ignore if it's actually a common use case or not, this is debatable. Let's ask: is it really something that is unique to Svelte and needs a tutorial at all? Svelte has so many amazing concepts and things that people need to understand (reactivity, binding, stores, actions). Using @html is almost trivial and not really something that is super Svelte specific. It's also something that someone can easily find via Google or the docs once their project has that requirement. It's really simple to grasp and you "gotcha" in three seconds. Other concepts on the other hand are way more important to create a successful Svelte project than the existence of @html.

but we've warned the user in the tutorial.

Assuming people actually read these things. I personally skim over texts at best, in the given case I'd just copy the code. In my case I know what I'm doing, but someone who doesn't just potentially added a security vulnerability.

I agree with @Marr11317 that the current situation can be improved. I wouldn't go as far as adding sanitation into Svelte itself, since this is an entire project on its own and you don't always need or want sanitation or you need control over its specifics. But for example the tutorial and docs could include https://github.com/cure53/DOMPurify/ with a comment inside the code.

<script>
    import DOMPurify from 'dompurify';

    let string = `this string contains some <strong>HTML!!!</strong>`;
</script>

<!-- Make sure to never use @html with untrusted input. If you have to, e.g. if you render user provided Markdown, make sure to sanitize the HTML for example using the DOMPurify library -->
<p>{@html DOMPurify.sanitize(string)}</p>

I'd also be +1 on @dangerousInnerHTML. Security is not one dimensional and "we mentioned it in the docs/tutorials" is just one of many things.

I'm -1 on removing @html. You could do bind:this + innerHTML but using raw DOM should only be an escape hatch and we lose control, e.g. by educating about the dangers of @html.

I don't really care about the position of it in the tutorial. Other than markdown rendering I've never needed @html and I think many projects never need it at all.