Element: setHTML() method

https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML

by todsacerdoti • 9 months ago

268 145 9 months ago

developer.mozilla.org

So is this basically a safe version of innerHTML?

Octoth0rpe• 9 months ago

Yes, although a slightly more relevant way of putting it would be that it's an inbuilt DOMPurify (dompurify being an npm package commonly used to sanitize html before injecting it).

ngold• 9 months ago

Is this basically doing the same thing as https now? But for http, and firefox just never implemented a simple fix for it's entire existence until now?

I obviously know nothing about this, but I still find it fascinating. Or am I off my block.

intrasight3• 9 months ago

I'm confused as to why you need a "safe" version if you're the one generating and injecting the HTML.

evbogue• 9 months ago

Why should a web page only have a single person generating and injecting HTML into it?

matmo• 9 months ago

Isn't this kinda like asking "why does my gun need a safety if I'm the only one consciously pulling the trigger"?

theendisney2• 9 months ago

It was kind of strange to have bbcode and wiki markup specifically to avoid allowing users to use html.

halapro3• 9 months ago

If you generate it from completely static and known values, have at it.

If you include user-provided data, then you should sanitize it for HTML.

jeroenhd• 9 months ago

As it turns out, verifying that HTML is safe to render without neutering HTML down to a whitelist of elements is actually quite difficult. That's not great when you're rendering user-generated content.

Solutions in the form of pre-existing HTML sanitisation libraries have existed for years but countless websites still manage to get XSS'd every year because not everyone capable of writing code is capable of writing secure code.

masklinn4• 9 months ago

1. Because you commonly are not.

2. Because it’s really easy to fuck up and leak attacker controlled content in markup, especially when the environment provides tons of tools to do things wrong and none to do things right. IME even when the environment provides tons of tools to do things right it’s an uphill battle (universe, idiots, yadda yadda).

zarzavat• 9 months ago

Markdown parsers output unsafe HTML.

idreyn• 9 months ago

It is to render untrusted (user-generated) HTML without letting them slip in markup like script tags that could harm other users.

bawolff5• 9 months ago

Because sometimes you generate html based on user input and upwards of 98% of web related security vulnerabilities have been this.

evilpie2• 9 months ago

We enabled this by default in Firefox Nightly (only) this week.

spankalee5• 9 months ago

I'll be very excited to use this in Lit when it hits baseline.

While lit-html templates are already XSS-hardened because template strings aren't forgeable, we do have utilities like `unsafeHTML()` that let you treat untrusted strings as HTML, which are currently... unsafe.

With `Element.setHTML()` we can make a `safeHTML()` directive and let the developer specify sanitizer options too.

StrauXX• 9 months ago

Why don't you use DOMPurify right now? It's battle tested and supports configs just like this proposal.

somat3• 9 months ago

So that's why template literals are broken. I am not much of a JS dev but sometimes I play one on TV. and I was cursing up a storm because I could not get templates to work the way I wanted them to. And I quote "What do you mean template strings are not strings? What idiot designed this."

If curious I had a bright idea for a string translation library, yes, I know there are plenty of great internationalization libraries, but I wanted to try it out. the idea was to just write normalish template strings so the code reads well, then the translation engine would lookup the template string in the language table and replace it with the translated template string, this new template string is the one that would be filled. But I could not get it to work. I finally gave up and had to implement "the template system we have at home" from scratch just to get anything working.

To the designers of JS template literals, I apologize, you were blocking an attack vector that never crossed my mind. It was the same thing the first time I had to do the cors dance. I thought it was just about the stupidest thing I had ever seen. "This protects nothing, it only works when the client(the part you have no control over) decides to do it" The idea that you need protection after you have deliberately injected unknown malicious code(ads) into your web app took me several days of hard thought to understand.

leenify3• 9 months ago

Thank you for the effort to bring this to life together with Freddy!

redbell• 9 months ago

This feature is not Baseline because it does not work in some of the most widely-used browsers.

This is interesting, but it appears to be in its early days as none of the major browsers seem to support it.. yet.

JadeNB• 9 months ago

A sibling comment by evilpie says that it is enabled in Firefox Nightly: https://news.ycombinator.com/item?id=45674985

MarsIronPI• 9 months ago

Actually, it exists behind an about:config as far back as 138. So if you enable it, it even works in the current ESR.

CaptainOfCoit• 9 months ago

Really happy to see it, after 25 years (https://www.bugcrowd.com/glossary/cross-site-scripting-xss/) of surviving without it. It always struck me as an obvious missing part of the DOM API, and I still don't know why it took this long time.

But mostly I'm just happy that it's finally here, I do appreciate all the hard work people been doing to get this live.

theendisney2• 9 months ago

Yes

<sc<script>ript>

bawolff5• 9 months ago

I think DOM api people just really wanted everyone to use .appendChild() methods.

I think there is an interesting lesson here about how security is partially an ergonomic problem.

AlienRobot2• 9 months ago

Great functionality, terrible name.

varun_ch• 9 months ago

I sometimes wonder whether what the DOM APIs could look like in a hypothetical world where we could start over with everything.

hexasquid2• 9 months ago

It looks like this isn't a standard yet.

jonathrg• 9 months ago

Why? Does it not set the HTML?

netsharc• 9 months ago

It doesn't say "There's a lot of hidden sanitizing stuff inside this method" from the name...

Something like "setSafeHTML()" would be preferable. (Since it's Mozilla, there should be a few committee meetings to come up with the appropriate name)...

AlienRobot2• 9 months ago

There is already an innerHTML property for elements. This doesn't set the outer HTML, so it's literally setInnerHTML2.

hexasquid2• 9 months ago

After a minute of digging, found discussion here: https://github.com/WICG/sanitizer-api/issues/100 Perhaps it can be reopened (or a new issue can be opened) regarding naming.

ajkjk• 9 months ago

The name seems ideal to me.

dzogchen• 9 months ago

Neat. I think once this is adopted by HTMX (or similar libraries) you don't need to sanitize on the server side anymore?

dylan6045• 9 months ago

Do you honestly feel that we will ever be in a place for the server to not need to sanitize data from the client? Really? I don't. Any suggestion to me of "not needing to sanitize data from client" will immediately have me thinking the person doing the suggesting is not very good at their job, really new, or trying to scam me.

There's no reason to not sanitize data from the client, yet every reason to sanitize it.

jsmith99• 9 months ago

It's arguably easier just to sanitise at display time otherwise you have problems like double escaping.

strbean5• 9 months ago

It can be a complicated and error-prone process, mainly in scenarios where you have multiple mediums that require different sanitizers. Obviously you should do it. But in such scenarios, the best practice is to sanitize as close to the place it is used as possible. I've seen terrible codebases where they tried to apply multiple layers of sanitization on user input before storing to the DB, then reverse the unneeded layers before output. Obviously this didn't work.

Point being, if you can move sanitization even closer to where it is used, and that sanitization is actually provided by the standard library of the platform in question, that's a massive win.

padjo4• 9 months ago

Sanitize as close as possible to where it is used is usually best, then you don’t have to keep track of what’s sanitized and what’s not sanitized for very long.

(Especially important if sanitation is not idempotent!)

auxiliarymoose3• 9 months ago

If you sanitize on the server, you are making assumptions about what is safe/unsafe for your clients. It's possible to make these assumptions correctly, but that requires keeping them in sync with all clients which is hard to do correctly.

Something that's sanitized from an HTML standpoint is not necessarily sanitized for native desktop & mobile applications, client UI frameworks, etc. For example, with Cloudflare's CloudBleed security incident, malformed img tags sent by origin servers (which weren't themselves by themselves unsafe in browsers) caused their edge servers to append garbage (including miscellaneous secure data) from heap memory to some requests that got indexed by search engines.

Sanitization is always the sole responsibility of the consumer of the content to make sure it presents any inbound data safely. Sometimes the "consumer" is colocated on the server (e.g. for server rendered HTML + no native/API users) but many times it's not.

wasmperson• 9 months ago

I interpreted your question as "do I now no longer need to escape user-generated data in the HTML sent by the server in response to requests by HTMX?" The short answer is no, you still need to escape it:

- HTMX adds extra significance to HTML attributes which aren't accounted for by the built-in sanitizer

- HTMX can't add a custom sanitizer because it wouldn't be able to distinguish between intentional and malicious uses of those attributes

- Even if the HTMX client library sanitized all of the HTML from the server, you can't guarantee that all requests to the server will come from HTMX: browsers can navigate to your "back-end" URLs directly. While you can protect yourself from this using HTTP headers, that's not something I'd feel comfortable relying on since it would be easy to not notice when you've accidentally gotten it wrong.

The HTMX website has a longer explainer on how to protect yourself from XSS when using the library:

https://htmx.org/essays/web-security-basics-with-htmx/

ishouldbework2• 9 months ago

It then removes any HTML entities that aren't allowed by the sanitizer configuration, and further removes any XSS-unsafe elements or attributes — whether or not they are allowed by the sanitizer configuration.

Emphasis mine. I do not understand this design choice. If I explicitly allow `script` tag, why should it be stripped?

If the method was called setXSSSafeSubsetOfHTML sure I guess, but feels weird for setHTML to have impossible-to-override filter.

evilpie2• 9 months ago

If you want to use an XSS-unsafe Sanitizer you have to use setHTMLUnsafe.

jmull• 9 months ago

I guess they are going for a safe default... the idea is people who don't carefully read the docs or carefully monitor the provenance of their dynamically generated HTML will probably reach for "setHTML()".

Meanwhile, there's "setHTMLUnsafe()" and, of course, good old .innerHTML.

strbean5• 9 months ago

This is primarily an ergonomic addition, so it kinda makes sense to me to not make the dangerous footguns more ergonomic in the process. You can still assign `innerHTML` etc. to do the dangerous thing.

hsbauauvhabzb• 9 months ago

Ideally this should be called dangerouslySetInnerHTML but hindsight blah blah

meowface2• 9 months ago

I agree, though I also agree with the parent that the method name is a little bit confusing. "safeSetHTML" or "setUntrustedHTML" or something would be clearer.

wewtyflakes• 9 months ago

Wouldn't that open the floodgates by allowing code that could itself call `setHTML` again but then further revise the args to escalate its privileges?

systoll• 9 months ago

A script tag would be able to call setHTMLUnsafe, bypassing whatever sanitation you configured.

I’d’ve made it a runtime error to call setHTML with an unsafe config, but Javascript tends toward implicit reinterpretation rather than erroring-out.

recursivecaveat• 9 months ago

You have to make the safe version the ergonomic one. Many many C++ memory bugs are a result of the standards committee making the undefined behaviour version of an operation even 3 characters shorter than the safe one. (They're still doing it too! I found another example added in C++23 recently)

masklinn4• 9 months ago

feels weird for setHTML to have impossible-to-override filter.

It really doesn’t. We’ve decades of experience telling us that safe behaviour is critical.

I do not understand this design choice. If I explicitly allow `script` tag, why should it be stripped?

Because there’s an infinitesimal number of situations where it’s not broken, and that means you should have to put in work to get there.

`innerHTML` still exists, and `setHTMLUnsafe` has no filtering whatsoever by default (not even the script deactivation innerHTML performs).

ishouldbework2• 9 months ago

I did not notice setHTMLUnsafe exists. That makes it (in my, unimportant, opinion) fine.

ibowankenobi3• 9 months ago

The API design could be better. Document fragments are designed to be reused. It should accept an optional fragment key which accepts a document fragment.If not a fragment, throw, if has children, empty contents first.

spankalee5• 9 months ago

In what way are document fragments meant to be reused?

They empty their contents into the new parent when they're appended, so they can't be meaningfully appended a second time without rebuilding them.

`<template>` is mean to be reused, since you're meant to clone it in order to use it, and then you can clone it again.

ibowankenobi3• 9 months ago

You can absolutely reuse a document fragment

https://ibrahimtanyalcin.github.io/Cahir/

the whole rendering uses a single fragment.

padjo4• 9 months ago

As someone who has dealt with more than my fair share of content injection vulnerabilities over the years this is great to see at last. It’s kinda crazy that this only coming now while other, more cumbersome solutions like CSP have been around for years.

modinfo• 9 months ago

Cursor build a pseudo-sethtml: https://github.com/skorotkiewicz/pseudo-sethtml

exdeejay_• 9 months ago

This code only does the most basic and naive regex filtering that even a beginner XSS course's inputs would work against. With the Node example code and input string:

  <p>Hello <scr<script>ipt>alert(1)</scr<script>ipt> World</p>

The program outputs:

  $ node .
  <p>Hello <script>alert(1)</script> World</p>
  {
    sanitizedHTML: '<p>Hello <script>alert(1)</script> World</p>',
    wasModified: true,
    removedElements: [],
    removedAttributes: []
  }

Asking a chatbot to make a security function and then posting it for others to use without even reviewing it is not only disrespectful, but dangerous and grossly negligent. Please take this down.

codedokode3• 9 months ago

I wonder why Cursor chose regex approach when it is widely known that it is a wrong method. Is it a result of training on low-quality forums for beginners?

sph• 9 months ago

  node.ts:52: const regex = new RegExp(`<\\/?${tag}[^>]*>`, "gi");
  node.ts:72: const regex = new RegExp(`\\s+${attr}\\s*=\\s*["'][^"']*["']`, "gi");
  node.ts:94: const tagRegex = /<(\w+)[^>]*>/g;

https://stackoverflow.com/questions/1732348/regex-match-open...

LLMs are not intelligent enough to figure that the post is non-satirical and you should indeed avoid parsing HTML with regexes.

On the other hand, there is a non-zero chance that a vibe coded HTML parser will eventually include obscure references to ritual infanticide and other eldritch entities of the Basic Multilingual Plane.

_the_inflator• 9 months ago

Maybe it is then time for having something that is beyond "use strict" at the beginning auf a JavaScript document as one option to use the statement.

I think a config object in which you define for script options like sanitization and other script configuration might be helpful.

After all, there almost always need to be backward compatibility be ensured, and this might work. I am no spec guy, it is just an idea. React makes use of "use client/server", so this would be more central and explicit.

ricardobeat• 9 months ago

ESM modules are already in strict mode by default.

rictic2• 9 months ago

A somewhat related spec, at the page level rather than the module level, are Content Security Policies, which let a page disable various unsafe browser features for a page: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

One of my favorite features in there is trusted types enforcement: https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Typ...

Lets you create your own API for what code is allowed to create arbitrary, potentially unsafe HTML at runtime, so you can allow secure templating systems but disallow code that just concats strings together naively.

cheeaun• 9 months ago

Found a polyfill here https://github.com/mozilla/sanitizer-polyfill

dkyc• 9 months ago

This just uses DOMPurify under the hood

Izkata• 9 months ago

...yes, that's what a polyfill is: a javascript implementation of a new spec that's only applied when the current browser doesn't yet support the new spec. This lets devs start using it right away, then when it has enough support across browsers the polyfill can be removed without changing their code.

sergeykish• 9 months ago

So `.setHTML("<script>...</script>")` does not set HTML?

xp844• 9 months ago

Sounds reasonable enough to me. 99.99% of the times you’re in an actual script, if you mean to execute code, you’d just execute it yourself, rather than making a script tag full of code and sticking that tag into a random DOM element. That’s why the default wouldn’t honor the script tag and there’d be an “unsafe” method explicitly named as such to hint you that you’re doing something weird.

amelius2• 9 months ago

But it breaks an abstraction. Sometimes you just want to take working HTML and insert it into a document. It will be painful if suddenly this does not work, and you have to dig into the documentation to see why.

WA• 9 months ago

Neither does

    .innerHTML = "<script>...</script>"

codedokode3• 9 months ago

I don't like this. This could be implemented as a JS library. I believe browsers should provide the minimal API so that they are smaller and easier to create. As for safe alternative to innerHTML, it is called innerText.

csmantle• 9 months ago

I think innerText and setHTML() have different purposes. The former inserts the whole string as a text leaf, while the latter tries to preserve structures that are meaningful in context.

---

Libraries can surely do the same job, but then the exact behavior would vary among a sea of those libs. Having specs defined [0] for such an interface would hopefully iron out much of these variations, as well as enabling some performance gains.

[0] https://wicg.github.io/sanitizer-api/#dom-element-sethtml

codedokode3• 9 months ago

And if you need something that is not in a spec, you have to use a library anyway. Also the point was that browser should be as simple as possible and not like a whole new OS.

codezero• 9 months ago

innerText has wildly inconsistent implementations across browsers.

petralithic• 9 months ago

I believe browsers should provide the minimal API so that they are smaller and easier to create.

That ship has long since sailed. Browsers are so complex that it takes quite some effort to support the various levels of 9s of the percentage of compatibility with standards, not to mention the browser makers themselves define many of the standards.

CGamesPlay2• 9 months ago

Is “XSS-unsafe” precisely defined anywhere? I assume it means “any access to the JS interpreter”, but assuming in this context seems decidedly unsafe.

pyth0• 9 months ago

It appears you can tune what is sanitized from the input via the "sanitizer" optional parameter. The default sanitizer is however defined in a spec linked on the docs page [1] with the actual sanitize operation specified as well [2].

[1] https://wicg.github.io/sanitizer-api/#dom-element-sethtml

[2] https://wicg.github.io/sanitizer-api/#sanitize

CGamesPlay2• 9 months ago

Ah, perfect, the "remove unsafe" operation is what I was looking for. It includes a list of elements and a list of attributes. These appear to apply regardless of the sanitizer configuration you use, the original MDN link demonstrates allowlisting "script" but seeing that it is removed anyways.

https://wicg.github.io/sanitizer-api/#sanitizerconfig-remove...

Traubenfuchs• 9 months ago

So this is the easier, built in successor to

    innerHTML = trustedTypes.createPolicy('myPolicy', {
  createHTML: (input) => DOMPurify.sanitize(input, {RETURN_TRUSTED_TYPE: true})

}).createHTML()

textlanes33• 9 months ago

This is goood news for me. Finally! A safer and more predictable alternative to innerHTML.

ulrischa2• 9 months ago

Since 5 years everybody says Jquery us no longer necessary. But really baisc function like this take a long time for replacing Jquery

halapro3• 9 months ago

jQuery does not sanitize HTML. This is why jQuery is no longer necessary, even if people think it is.

ulrischa2• 9 months ago

There is the jquery bashing again. let sanitizedHTML = $('<div>').text(unsanitizedHTML).html();

awayredbarron• 9 months ago

Verbose I/O element

Parsing > "DocumentFragment"

Returns proc. exit status [0]/[1] for browser HTML incompatability.

xnorswap• 9 months ago

That's really good to hear.

I've found LLMs will happily generate XSS vulnerable code, which will make things worse for a while until they can be trained better.

In fact, I found it really difficult to get claude-code to use templating libraries and not want to default to hand-written templating with XSS vulnerabilties and injecting content directly, even after going through options with it.

There's also a difference between escaping and sanitisation which can be tricky to handle and track, and it can even be dangerous to try to mix different approaches or sanitizers.

Having a safe backstop in the form of setHTML() to use will be a fantastic addition to narrow the scope of ways to get it wrong.

tartoran• 9 months ago

This whole page renders extremely poorly on mobile, beyond usable I'd say.

waldothedog• 9 months ago

Working well for me on mobile!

erickotato• 9 months ago

I don't really get it. Why this is needed on client? If all we want is to prevent XSS attacks, wouldn't it be more effective to sanitize on server? Am I missing something?

Element: setHTML() method

Related Stories