You are right that the concept of "safe" is nebulous, but the goal here is specifically to be XSS-safe [1]. Elements or properties that could allow scripts to execute are removed. This functionality lives in the user agent and prevents adding unsafe elements to the DOM itself, so it should be easier to get correct than a string-to-string sanitizer. The logic of "is the element currently being added to the DOM a <script>" is fundamentally easier to get right than "does this HTML string include a script tag".

[1] https://developer.mozilla.org/en-US/docs/Web/API/Element/set...

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.

the browser-native Sanitizer API has one advantage the library approaches don't: it uses the same HTML parser the browser uses to render. libraries like DOMPurify parse in a separate context then re-serialize, and historically that round-trip is where most bypasses came from. when the sanitizer and the renderer share the same parser, mutation XSS attacks have nowhere to hide.

They do link the default configuration for "safe": https://wicg.github.io/sanitizer-api/#built-in-safe-default-...

But I agree, my default approach has usually been to only use innerText if it has untrusted content:

So if their demo is this:

    container.SetHTML(`<h1>Hello, {name}</h1>`);

Mine would be:

    let greetingHeader = container.CreateElement("h1");
    greetingHeader.innerText = `Hello, {name}`;

fwiw, if you serve your page with:

Content-Security-Policy: require-trusted-types-for 'script'

…then it blocks you from passing regular strings to the methods that don't sanitize.

Some sanitization is better than none? If you're relying on the browser to handle it for you, you're already in a lot of trouble.

realSetSafeHTML()

`setHTML` is meant as a replacement for `innerHTML`. In the use case you describe, you would have never wanted `innerHTML` anyway. You'd want `innerText` or `textContent`.

> If the default configuration of setHTML( ) is too strict (or not strict enough) for a given use case, developers can provide a custom configuration that defines which HTML elements and attributes should be kept or removed.

    document.createElement("h1").textContent = `Hello, ${username}!`

If I'm reading this right,

    .setHTML("<h1>Hello</h1>", new Sanitizer({}))

will strip all elements out. That's not too difficult.

Plus this is defense-in-depth. Backends will still need to sanitize usernames on some standard anyhow (there's not a lot of systems out there that should take arbitrary Unicode input as usernames), and backends SHOULD (in the RFC sense [1]) still HTML-escape anything they output that they don't want to be raw HTML.

[1]: https://www.rfc-editor.org/rfc/rfc2119

> but this still allows arbitrary markup to the page (even <style> CSS rules) if I'm reading the docs correctly.

If that's true, seems like it's still a security risk given what you can do with CSS these days: https://news.ycombinator.com/item?id=47132102

> Who would ever want this?

The main case I can think of is wanting some forum functionality. Perhaps you want to allow your users to be able to write in markdown. This would provide an extra layer of protection as you could take the HTML generated from the markdown and further lock it down to only an allowed set of elements like `h1`. Just in case someone tried some of the markdown escape hatches that you didn't expect.

> So you can still inject <h1> or <br><br><br>... etc into your username, in the given example

How exactly, given that setHTML sanitizes the input? If you don't want to have any HTML tags allowed, seems you can configure that already? https://wicg.github.io/sanitizer-api/#built-in-safe-default-...

    <h1>Hello my name is</h1>

Indeed, as any browser API, it might be for in a few years (months if happy with the most recent versions), and we may have polyfills in the meantime.

Using an allowlist based Sanitizer you are definitely less likely to shoot yourself in the foot, but as long as you use setHTML you can't introduce XSS at least.

When browsers implement a variant that lets you separate data and code perhaps. That's what I expected when reading the headline: setHtml(code, data, data, ...), just like parameterised SQL works: prepare("select rowid from %s where time < %n", tablename, mynumber)

This new method they've cooked up would be called eval(code,options) if html was anything other than a markup language