Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

2/24/2026 at 1:29:27 PM

This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But you can't easily do that down the line.

I'm also rather sceptical of things that "sanitise" HTML, both because there's a long history of them having holes, and because it's not immediately clear what that means, and what exactly is considered "safe".

by entuno

2/24/2026 at 2:03:09 PM

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

by jncraton

2/24/2026 at 5:12:28 PM

It's certainly an improvement over people trying to homebrew their own sanitisers. But that distinction of being XSS-safe is a potentially subtle one, and could end up being dangerous if people don't carefully consider whether XSS-safe is good enough when they're handling arbitrary users input like that.

by entuno

2/24/2026 at 5:21:56 PM

Also has made me nervous for years that there's been no schema against which one can validate HTML. "You want to validate? Paste your URL into the online validation tool."

by intrasight

2/24/2026 at 9:22:29 PM

This help? https://github.com/validator/validator

But for html snippets you can pretty much just check that tags follow a couple simple rules between <> and that they're closed or not closed correctly.

by Dylan16807

2/24/2026 at 9:50:42 PM

That app does look helpful!

by intrasight

2/24/2026 at 8:34:20 PM

> it's not at all clear which is which from the names. Ideally you design that in from the [start]

It was, and there is: setting elementNode.textContent is safe for untrusted inputs, and setting elementNode.innerHTML is unsafe for untrusted inputs. The former will escape everything, and the latter won't escape anything.

You are right that these "sanitizers" are fundamentally confused:

> "HTML sanitization" is never going to be solved because it's not solvable.¶ There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement.

<https://news.ycombinator.com/item?id=46222923>

The Web platform folks who are responsible for getting fundamental APIs standardized and implemented natively are in a position to know better, and they should know better. This API should not have made it past proposal stage and should not have been added to browsers.

by cxr

2/24/2026 at 9:13:08 PM

> There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement.

It is not a hard requirement that untrusted input is "treated like text". And this API lets you customize exactly what tags/attributes are allowed in the untrusted input. That's way better than telling everyone to write their own; it's not trivial.

by Dylan16807

2/24/2026 at 11:57:55 PM

It is not a hard requirement that untrusted input is "treated like text".

It's also not a hard requirement that I defend the position that there's a hard requirement for untrusted input to be treated like text. That isn't my position, and it's not what I wrote.

Given that it is not a hard requirement that untrusted input be treated like text, it wouldn't make sense for anyone to claim that it is—and therefore it doesn't make sense for someone, presented with I did write, to strenuously argue with me that such a tortured, implausible, uncharitable, non-sensical interpretation of what I wrote was something that I have to account for (versus the interpretation that does match what I wrote and is actually true and makes sense).

You are, willfully or not, misconstruing what I have written.

> That's way better than telling everyone to write their own; it's not trivial.

Right, it's not trivial. It's so far the opposite of trivial that it's (as I said the first time—and again, just now) not solvable.

No one should be writing their own.

No one should be trying to write their own.

No one should be using this API at all.

And no one should have pushed for its implementation.

It's a bad API.

by cxr

2/25/2026 at 12:22:54 AM

I thought you were done talking to me?

Briefly though, if you have an untrusted string then you need to either treat it like text or sanitize it. I don't see any other options.

So if people shouldn't use this sanitizer or write their own, then the only option left is treating the string as text. But you're vehemently arguing that's not what you said.

What's the other way to use an untrusted string? Other than "don't", but that means not taking input and only works for toy apps.

by Dylan16807

2/24/2026 at 9:18:24 PM

[flagged]

by cxr

2/24/2026 at 9:40:38 PM

I don't see how I differed from what you said? You divided strings going into HTML into two categories, where one category uses textContent and the other category uses innerHTML. My point is to disagree with those categories, not whatever subtle thing you're taking issue with.

by Dylan16807

2/24/2026 at 9:46:20 PM

[flagged]

by cxr

2/24/2026 at 10:02:56 PM

This is a totally different kind of statement. You're not dividing tax returns into two categories and then saying what to do with each category.

Those claims are different but not in a way that analogizes to the HTML conversation.

by Dylan16807

2/24/2026 at 10:11:17 PM

I'd say I'm interested in hearing how you reason that knowing whether you need to pay at least $1000 in unpaid taxes to the IRS doesn't put you in one bucket or another, but I'm not.

by cxr

2/24/2026 at 10:39:25 PM

The IRS thing indirectly has categories but it doesn't say what to do with them, and what to do with them is what I disagreed with your original post on. I didn't say all input is untrusted or whatever analogizes to your tax thing.

Anyway, I see you edited your previous post after I wrote my reply.

If you weren't trying to divide things into two categories, you wrote it very confusingly. When you say how to handle trusted strings, then say how to handle untrusted strings, then say "There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement." it really sounds like that's supposed that's supposed to cover all cases.

Me thinking you were using two categories is an honest mistake, not malicious misquoting.

And reading your original post that way is the interpretation that makes it stronger. If there are more categories then SetHTML is no longer "fundamentally confused". Your argument against it falls apart.

by Dylan16807

2/24/2026 at 11:40:27 PM

Guess how interested I am in pretending that a debate with you—about this or anything else—is worthwhile (or anything, really, other than an even bigger waste of time than it already has been).

by cxr

2/24/2026 at 1:43:46 PM

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.

by voxic11

2/24/2026 at 2:51:36 PM

I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year.

Good idea to ship that one first, when it's easier to implement and is going to be the unsafe fallback going forward.

by extraduder_ire

2/24/2026 at 4:38:07 PM

I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year.

Oddly though, the Sanitizer API that it's built on doesn't appear to be in Safari. https://developer.mozilla.org/en-US/docs/Web/API/Sanitizer

by onion2k

2/24/2026 at 2:22:33 PM

If I need the old functionality why not stick to innerHTML?

by croes

2/24/2026 at 2:39:03 PM

because the "unsafe" suffix conveys information to the reader, whereas `innherHTML` does not?

by orf

2/24/2026 at 3:39:03 PM

Any potential reader should be familiar with innerHTML.

by goatlover

2/24/2026 at 4:11:06 PM

Right. Like how any potential reader is familiar with the risks of sql injection which is why nothing has ever been hacked that way.

Or how any potential driver is familiar with seat belts which is why everybody wears them and nobody’s been thrown from a car since they were invented.

by kennywinker

2/24/2026 at 4:34:14 PM

yes, and bugs shouldn't exist because everyone should be familiar with everything.

by orf

2/24/2026 at 5:43:30 PM

But if some are marked unsafe and others are not it gives a false sense of security if something is not marked unsafe.

by croes

2/24/2026 at 5:45:29 PM

So we shouldn’t mark anything as unsafe then? And give no indication whatsoever?

The issue isn’t that the word “safe” doesn’t appear in safe variants, it’s that “unsafe” makes your intentions clear: “I know this is unsafe, but it’s fine because of X and Y”.

by orf

2/24/2026 at 6:23:34 PM

Maybe we should add the word safe and consider everything else as unsafe

by croes

2/24/2026 at 7:07:42 PM

Like life, things should default to being safe. Unsafe, unexpected behaviours should be exception and thus require an exceptional name.

Legacy and backwards compatibility hampers this, but going forward…

by orf

2/24/2026 at 2:48:48 PM

Because then your linter won't be able to tell you when you're done migrating the calls that can be migrated.

by tbrownaw

2/24/2026 at 4:25:12 PM

Because sooner or later it'll be removed.

by philipwhiuk

2/24/2026 at 5:54:39 PM

No because the web has to remain backwards compatible with older sites. This has always been the case.

by goatlover

2/24/2026 at 5:44:08 PM

And break millions of sites?

by croes

2/24/2026 at 2:41:05 PM

You can't rename an existing method. It would break compatibility with existing websites.

by reddalo

2/24/2026 at 2:01:18 PM

> you would eliminate all usage of innerHTML

The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened.

I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.

by post-it

2/24/2026 at 2:19:07 PM

If you want to adopt this in your project, you can add a linter that explicitly bans innerHTML (and then go fix the issues it finds). Obviously Mozilla cannot magically fix the code of every website on the web but the tools exist for _your_ website.

by thenewnewguy

2/24/2026 at 2:18:46 PM

I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore.

(Assuming transpilers have stopped outputting it, which I'm not confident about.)

by Vinnl

2/24/2026 at 6:37:42 PM

Actually... https://github.com/microsoft/TypeScript/issues/52924

by yawaramin

2/24/2026 at 6:56:14 PM

Ah yeah, I remember that. General point still stands: in terms of the lived experience of developers, `var` is essentially deprecated.

by Vinnl

2/24/2026 at 8:11:41 PM

I touch JS that uses var heavily on a daily basis and I would be incredibly surprised to find out that I am alone in that.

by plorkyeran

2/25/2026 at 9:55:34 AM

That is indeed why I added qualifiers to "everyone" and "never".

by Vinnl

2/24/2026 at 2:36:16 PM

for some values of "everyone" and "never".

by delaminator

2/24/2026 at 2:33:45 PM

Depending on the transpiler and mode of operation, `var` is sometimes emitted.

For example, esbuild will emit var when targeting ESM, for performance and minification reasons. Because ESM has its own inherent scope barrier, this is fine, but it won't apply the same optimizations when targeting (e.g.) IIFE, because it's not fine in that context.

https://github.com/evanw/esbuild/issues/1301

by thunderfork

2/24/2026 at 2:36:49 PM

It for sure happens for drop in replacements.

by bulbar

2/24/2026 at 3:38:25 PM

Nobody's talking about old code here.

Having an alternative to innerHTML means you can ban it from new code through linting.

by littlestymaar

2/24/2026 at 2:08:11 PM

Finally, a good use case for AI.

by noduerme

2/24/2026 at 2:33:39 PM

Yeah, using a kilowatt GPU for string replacement is going to be the killer feature. I probably shouldn't even be joking, people are using it like this already

by Aachen

2/24/2026 at 2:36:16 PM

When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.

by charcircuit

2/24/2026 at 3:04:47 PM

This one is literally matching "innerHTML = X" and setting "setHTML(X)" instead. Not some complex data format transformation

But I can see what you mean, even if then it would still be better for it to print the code that does what you want (uses a few Wh) than doing the actual transformation itself (prone to mistakes, injection attacks, and uses however many tokens your input data is)

by Aachen

2/24/2026 at 4:18:02 PM

That can break the site if you do the find and replace blindly. The goal here is to do the refactor without breaking the site.

by charcircuit

2/24/2026 at 6:24:44 PM

> When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.

And, in your opinion, this is one of those cases?

by lelanthran

2/24/2026 at 10:35:18 PM

It is because the new API purposefully blocks things the old API did not.

by charcircuit

2/24/2026 at 3:39:53 PM

This ship has sailed unfortunately, no later than yesterday I've seen coworkers redact a screenshot using chatGTP.

by littlestymaar

2/24/2026 at 2:15:49 PM

Wouldn't AI be trained on data using innerHTML?

by josefx

2/24/2026 at 2:35:17 PM

My experience is that they somehow print quite modern code despite things like ES6 being too new to be standard knowledge even for me and I'm not even middle-aged yet

Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output? Or maybe they assign higher weights to more recent commits/sources during training? Not sure but it seems to be good at picking this up. And you can always feed the info into its context window until then

by Aachen

2/24/2026 at 3:15:41 PM

This is not my experience. Claude has been happily generating code over the past week that is full of implicit any and using code that's been deprecated for at least 2 years.

>> Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output?

The rate of change has made defining "modern" even more difficult and the timeframe brief, plus all that new code is based on old code, so it's more like a leaning tower than some sort of solid foundation.

by skeeter2020

2/24/2026 at 4:53:29 PM

ES6 is 11 years old. It's not that new.

by SahAssar

2/25/2026 at 1:35:51 PM

Hence the example of how long it takes non-LLMs to pick that up, whereas LLMs seem to get it despite there being loads of old code out there

See also my reply to the sibling comment with the same remark https://news.ycombinator.com/item?id=47151211

My mistake for saying 10 instead of 11 years btw, but I don't think it changes the point

by Aachen

2/24/2026 at 5:53:37 PM

> "ES6 being too new to be standard knowledge"

Huh? It's been a decade.

by chrisweekly

2/25/2026 at 1:29:24 PM

Exactly, I learned coding JS before 2015 (it was my first language, picked up during what is probably called middle school in english). I haven't had to learn it again from scratch, so I need to go out of my way to find if there is maybe a better way to do the thing I can already do fine. It's not automatic knowledge, yet the LLM seems to have no trouble with it, so I'm pointing out that they seem to not have problems upgrading. The grandparent comment suggested it would need to be trained anew to use this new method instead. Given how much old (non-ES6) JS there is, apparently it gets it quite easily so any update that includes some amount of this new code will probably do it just fine

by Aachen

2/24/2026 at 2:37:03 PM

Which is why it can easily understand how innerHTML is being used so that it can replace it with the right thing.

by charcircuit

2/24/2026 at 2:37:17 PM

Honest question: Is there a way to get an LLM to stop emitting deprecated code?

by stvltvs

2/24/2026 at 2:39:53 PM

Theoretically, if you could train your own, and remove all references to the deprecated code in the training data, it wouldn't be able to emit deprecated code. Realistically that ability is out of reach at the hobbiest level so it will have to remain theoretical for at least a few more iterations of Moore's law.

by fragmede

2/24/2026 at 3:37:55 PM

Ideally you should be able to set a global property somewhere (as a web developer) that disallows outdated APIs like `innerHTML`, but with the Big Caveat that your website will not work on browsers older than X. But maybe there's web standards for that already, backup content if a browser is considered outdated.

by Cthulhu_

2/24/2026 at 8:56:12 PM

It's not an "outdated API". It's still good for what it was always meant for: parsing trusted, application-generated markup and atomically inserting it into the content tree as a replacement for a given element's existing children.

> set a global property somewhere (as a web developer) that disallows[…] `innerHTML`

    Object.defineProperty(Element.prototype, "innerHTML", {
      set: (() => { throw Error("No!") })
    });

(Not that you should actually do this—anyone who has to resort to it in their codebase has deeper problems.)

by cxr

2/24/2026 at 3:52:40 PM

Doesn't using TrustedTypes basically do that? I'm not really web-y, someone please correct me if I'm off.

by staticassertion

2/24/2026 at 5:03:15 PM

Yup, this is basically what TrustedTypes is for!

by madeofpalk

2/24/2026 at 3:44:27 PM

I like the idea of that. But I imagine linting rules are a much more immediate answer in a lot of projects.

by afavour

2/24/2026 at 2:54:18 PM

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.

by jaffathecake

2/25/2026 at 3:25:12 AM

Yeah someone tells me something has been made “safe” is nice but unless I know exactly what that means … it’s easy to say safe by someone who doesn’t have to deal with it when the bad corner case happens.

Oh and it’s safe… in this browser… not that one, so this idea of safety is kinda dead to me for now.

by duxup

2/24/2026 at 1:59:44 PM

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}`;

by DoctorOW

2/24/2026 at 2:58:10 PM

What if I wanted an <h2>?

Edit: I don't mean this flippantly. If I want to render, say, my blog entry on your site, will I need to select every markup element from a dropdown list of custom elements that only accept text a la Wordpress?

by itishappy

2/24/2026 at 10:28:38 PM

If it's anything complex I'm doing it server side, personally

by DoctorOW

2/25/2026 at 3:23:07 AM

That works fine. That said, client side JS solutions are already quite popular.

by itishappy

2/24/2026 at 5:30:13 PM

That's why I only allow user input of alphanumeric ascii characters. No need to worry about sanitation then, and you can just remove all the characters that don't match.

(It's a joke, but it is also 100% XSS, SQL injection, etc. safe and future proof)

by HWR_14

2/24/2026 at 2:07:21 PM

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.

by noduerme

2/24/2026 at 1:59:52 PM

realSetSafeHTML()

by post-it

2/24/2026 at 8:27:10 PM

> I'm also rather sceptical of things that "sanitise" HTML, both because there's a long history of them having holes, and because it's not immediately clear what that means, and what exactly is considered "safe".

What is safe depends on where the sanitized HTML is going, on what you're doing with it.

It isn't possible to "sanitize HTML" after collecting it so that, when you use it in the future, it will be safe. "Safe" is defined by the use.

But it is possible to sanitize it before using it, when you know what the use will be.

by thaumasiotes

2/24/2026 at 2:04:59 PM

[dead]

by snowhale

2/24/2026 at 2:52:40 PM

BTW, HTML allows inline SVG with an XML-flavored syntax that interprets <script/> and <title> differently. It's a goldmine for sanitizer escapes. There are completely bonkers syntax switching and error recovery rules that interact with parsing modes (there's even an edge case where a particular attribute value switches between HTML and XML-ish parsing rules).

Don't even try to allow inline <svg> from untrusted sources! (and then you still must sanitise any svg files you host)

by pornel

2/24/2026 at 3:55:15 PM

If you just serve SVGs through <img> tag it’ll be much safer. I never understood the appeal of inline <svg> anyways.

by kccqzy

2/24/2026 at 5:19:58 PM

Inline SVG is stylable with CSS styles in the same HTML page.

by lenkite

2/24/2026 at 7:01:06 PM

Also animatible with the same context (Animation API, etc.) as the parent page, so different SVGs can influence each other’s animations.

by runarberg

2/24/2026 at 4:58:04 PM

Inline reduces round trips.

by rwj

2/24/2026 at 5:11:12 PM

You can use img with a data url?

by toast0

2/24/2026 at 8:46:14 PM

It may be using some of the same deserialization machinery, but "parsing" is a broad term that includes things that the sanitizer is doing and that the browser's ordinary content-processing → rendering path does not.

Even with this being a native API, there are still two parsers that need to be maintained. What a native API achieves is to shift the onus for maintaining synchronicity between the two onto the browser makers. That's not nothing, but it's also not the sort of free lunch that some people naively believe it is.

by cxr

2/24/2026 at 4:35:27 PM

it's not at all clear which is which from the names

There's setHTML and setHTMLUnsafe. That seems about as clear as you can get.

by onion2k

2/24/2026 at 5:16:21 PM

If that'd been the design from the start, then sure. But it's not at all obvious that setHTML is safe with arbitrary user input (for a given value of "safe") and innerHTML is dangerous.

by entuno

2/24/2026 at 4:40:38 PM

But you can use InnerHTML to set HTML and that's not safe.

by hahn-kev

2/24/2026 at 5:41:54 PM

At this point that API has been around for decades and is probably impossible to deprecate without breaking fairly large amounts of the web. The only option is to introduce a new and better API, and maybe eventually have the browser throw out console warnings if a page still uses the old innerHTML API. I doubt any browser vendor will be gung ho enough to actually remove it for a very long time.

by onion2k

2/24/2026 at 2:22:46 PM

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

Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even <style> CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?

by Aachen

2/24/2026 at 2:32:09 PM

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

by cogman10

2/24/2026 at 2:41:11 PM

> This would provide an extra layer of protection

I think this might be the answer. There's no point to it by itself (either you separate data and code or you don't and let the user do anything to your page), but if you're already using a sanitiser and you can't use `textContent` because (such as with Markdown) there'll be HTML tags in the output, then this could be extra hardening. Thanks!

by Aachen

2/24/2026 at 6:43:21 PM

You'd never want to store the processed HTML anyway, this is website building 101.

by iLoveOncall

2/24/2026 at 8:59:25 PM

I store both, to serve processed HTML faster, and to be able to rebuild it just in case. Is this ok?

by efilife

2/25/2026 at 1:53:10 AM

I wouldn't trust myself to always remember to sanitize it, and in a company with more than one person, it becomes impossible to ensure it is properly handled.

by joquarky

2/24/2026 at 3:33:54 PM

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

by piccirello

2/24/2026 at 6:44:34 PM

But that's what setHTML isn't at all a replacement for innerHTML.

You still need innerHTML when you want to inject HTML tags in the page, and you could already use innerText when you didn't want to.

Having something in between is seriously useless.

by iLoveOncall

2/24/2026 at 9:30:06 PM

> You still need innerHTML when you want to inject HTML tags in the page

What makes you say this?

by Dylan16807

2/25/2026 at 1:56:51 AM

> need innerHTML

parent.appendChild(document.createElement(tag))

by joquarky

2/25/2026 at 8:32:34 AM

How is adding an element to the parent the same as replacing all the content of the element? You guys are exhausting. Think a bit before spouting nonsense?

by iLoveOncall

2/24/2026 at 3:02:40 PM

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

by itishappy

2/24/2026 at 3:07:41 PM

Injecting markup into someone else's website isn't what I'd call too strict a default configuration

If you mean to convey that it's possible to configure it to filter properly, let me introduce you to `textContent` which is older than Firefox (I'm struggling to find a date it's so old)

by Aachen

2/24/2026 at 3:11:20 PM

That's the whole point of the setHTML.

How would I set a header level using textContent?

by itishappy

2/24/2026 at 3:20:38 PM

The traditional way: separating data and code

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

If you allow <h1> in the setHTML configuration or use the default, users with the tag in their username also always get it rendered as markup

by Aachen

2/24/2026 at 3:43:19 PM

It sounds like you're arguing against a specific usecase, rather than the technology itself. If you don't want arbitrary markup in usernames, setHTML would absolutely be the wrong choice, but that's not really a good argument against setHTML.

by itishappy

2/24/2026 at 3:27:29 PM

Which is why you only use it where you want to allow some kind of html..?

by matsemann

2/24/2026 at 2:42:11 PM

> 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

by byproxy

2/24/2026 at 3:28:32 PM

You can use selectors to gain some information about things like input fields, e.g. https://www.invicti.com/blog/web-security/private-data-stole...

Or I guess you could completely restyle and change the text of UI elements so it looks like the user is doing one thing when they're actually doing something completely different like sending you money

by circuit10

2/24/2026 at 4:05:47 PM

Back in 2002 (?) I got banned from a certain auction site because I managed to inject HTML into my username that made it so once I had bid the "Bid" button disappeared for all subsequent users.

by qingcharles

2/24/2026 at 3:17:09 PM

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

by jerf

2/24/2026 at 5:25:58 PM

You aren't reading it right.

  new Sanitizer({})

This Sanitizer will allow everything by default, but setHTML will still block elements/attributes that can lead to XSS.

You might want something like:

  new Sanitizer({ replaceWithChildrenElements: ["h1"], elements: [], attributes: [] })

This will replace <h1> elements with their children (i.e. text in this case), but disallow all other elements and attributes.

by evilpie

2/24/2026 at 3:37:24 PM

i think the use case for setHTML is for user content that contains rich text and to display that safely. so this is not an alternative for escaping text or inserting text into the DOM but rather a method for displaying rich text. for example maybe you have an editor that produces em, and strong tags so now you can just whitelist those tags and use setHTML to safely put that rich text into the DOM without worrying about all the possible HTML parsing edge cases.

by benmmurphy

2/24/2026 at 2:26:10 PM

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

by embedding-shape

2/24/2026 at 2:29:32 PM

> How exactly, given that setHTML sanitizes the input?

The article says that the output is:

    <h1>Hello my name is</h1>

So it keeps (non-script) html tags (and presumably also attributes) in the input. Idk how you're asking "how" since it's the default behavior

Stripping HTML tags completely has always been possible with the drop-in replacement `textContent`. Making a custom configuration object for that is much more roundabout

by Aachen

2/24/2026 at 2:31:57 PM

Yes, because that's the default configuration, if you don't want that, stop using the default configuration? It's still sanitizing away the common XSS holes, hence it's a safer alternative to .innerHTML, and a more flexible alternative to .innerText

by embedding-shape

2/24/2026 at 2:49:06 PM

Shouldn't use innerText anyway (nonstandard, worse performance, tries to parse the HTML and gives you unexpected behavior if e.g. a style is set that makes an element invisible but still has text inside, doesn't work on all DOM nodes...)

I can see how it's a way of allowing some tags like bold and italic without needing a library or some custom parser, but I didn't understand what the point of this default could be and so why it exists (a sibling comment proposed a plausible answer: hardening on top of another solution)

> Yes, because that's the default configuration, if you don't want that, stop using the default configuration?

"don't use it if it's not what you want" is perhaps the silliest possible answer to the question "what's the use-case for this"

by Aachen

2/24/2026 at 2:54:22 PM

> Shouldn't use innerText anyway (nonstandard, worse performance, tries to parse the HTML and gives you unexpected behavior if e.g. a style is set that makes an element invisible but still has text inside, doesn't work on all DOM nodes...)

Maybe you meant .innerHTML? .innerText AFAIK doesn't try to parse HTML (why would it?), but I don't understand what you mean with nonstandard, both .innerHTML and .innerText are part of the standards, and I think they've been for a long time.

> but I didn't understand what the point of this default could be and so why it exists (a sibling comment proposed a plausible answer: hardening on top of another solution) [...] the question "what's the use-case for this"

I guess maybe third time could be the charm: it's for preventing XSS holes that are very common when people use .innerHTML

by embedding-shape

2/24/2026 at 3:15:55 PM

> maybe third time could be the charm: it's for preventing XSS holes

That information is in the question, so sadly no this still doesn't make sense to me because I don't understand any scenario in which this is what the developer wants. You always still need more code (to filter the right tags) or can just use textContent (separating data and code completely, imo the recommended solution)

> Maybe you meant .innerHTML? .innerText AFAIK doesn't try to parse HTML (why would it?)

No, I didn't mean that, yes it does, and no I don't know why it is this way. If you don't believe me and don't want to check it out for yourself, I'm not sure what more I can say

by Aachen

2/24/2026 at 6:36:18 PM

> I don't understand any scenario in which this is what the developer wants.

Client-side includes.

by lelanthran

2/24/2026 at 2:59:11 PM

It seems like the goal of the default configuration is preventing script injection while being otherwise very permissive. Basically, "safer than innerHTML, even when used very lazily". But I would expect guidance to evolve saying that it almost never makes sense to use the default and instead to specify a configuration that makes contextual sense for a given field.

The default might be suitable for something like an internal blog where you want to allow people to sometimes go crazy with `<style>` tags etc, just not inject scripts, but I would expect it to almost always make sense to define a specific allowed tag and attribute list, as is usually done with the userland predecessors to this API.

by benregenspan

2/24/2026 at 3:50:21 PM

There’s innerText if you don’t want markup. Or more verbosely, document.createTextNode followed by whatever.appendChild.

by kccqzy

2/24/2026 at 3:47:26 PM

> Who would ever want this?

Anyone who wants to provide some level of flexibility but within bounds. Say, you want to allow <strong> and <em> in a forum post but not <script>. It's not too difficult to imagine uses.

by afavour

2/24/2026 at 6:03:54 PM

Forums would already have code that sanitizes user input when it's submitted. Users aren't directly setting html elements.

by goatlover

2/24/2026 at 6:10:04 PM

And is that sanitization perfect? Kept up to date?

With a safe API like this one that's tied to the browser's own interpretation of HTML (i.e. it is perfectly placed to know exactly what is and isn't dangerous given it is the one rendering it) wouldn't it be much better to rely on that?

by afavour

2/24/2026 at 6:32:15 PM

> Who would ever want this?

Your lack of imagination is disturbing :-)

https://github.com/lelanthran/ZjsComponent

by lelanthran

2/24/2026 at 4:42:33 PM

> So you can still inject <h1> or <br><br><br>... etc into your username

Are we taking out all the fun of the web? I absolutely loved the <marquee> names people had in the early days of Facebook, it was all harmless fun.

If injection of frontend code takes down your backend, your backend sucks, fix it.

by dheera

2/24/2026 at 1:30:51 PM

Great to see this start to show up, but it looks like it will be a while before browser support is widely distributed enough to rely on it being present: https://caniuse.com/mdn-api_element_sethtml

by simonw

2/24/2026 at 1:44:33 PM

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.

by jraph

2/24/2026 at 1:53:06 PM

I wouldn't advise polyfills on this one, it entirely depends on the browser ability to evaluate cross scripting and cross origin rule on a arbitrary snippet. This is not a convenience API.

by tuyiown

2/24/2026 at 5:42:19 PM

Title was a bit rage-baity. And I think you can already do sanitation by writing a function to check input before passing it to innerHTML?

This really just seems like another attempt at reinventing the wheel. Somewhat related, I find it ironic how i cannot browse hacks.mozilla.org in my old version of firefox("Browser not supported"). Also, developer.mozilla.org loads mangled to various degrees in current versions of palemoon, basilisk, and seamonkey

It's like there is some sort of "browser cartel" trying to screw up The Web.

by dogtimeimmortal

2/24/2026 at 5:45:32 PM

> you can already do sanitation by writing a function to check input before passing it to innerHTML

This is like saying C is memory safe as long as your code doesn't have any bugs.

More saliently, it does not consider parser differentials.

by Retr0id

2/24/2026 at 2:26:40 PM

Seems like this has a bunch of footguns. Particularly if you interact with the Sanitizer api, and particularly if you use the "remove" sanitizer api.

Don't get me wrong, better than nothing, but also really really consider just using "setText" instead and never allow the user to add any sort of HTML too the document.

by cogman10

2/24/2026 at 2:47:48 PM

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.

by evilpie

2/24/2026 at 6:38:13 PM

> never allow the user to add any sort of HTML too the document.

What about when the author of the page wants to add large html fragments to the page?

Are you saying that you cannot think of a single use for this, considering how often innerHTML is being used?

by lelanthran

2/24/2026 at 5:29:17 PM

It's worse than nothing, since inevitably people will use this thinking it's 100% safe when it's not.

by GalaxyNova

2/24/2026 at 1:50:40 PM

This is nice. The best part is that all aspects of network access are now properly controlled so that security transitioned from a chain of trusted code to a chain of trusted security setup on hosts, with existing workable safe defaults.

by tuyiown

2/24/2026 at 9:12:52 PM

What I really want is a <sandbox> element that can safely run dangerous code, not something that modifies dangerous code.

Iframes have significant restrictions as they can’t flow with the DOM. With AI and the increase in dynamic content, there’s going to be even more situations where you run untrusted code. I want configurable encapsulation.

by jjcm

2/24/2026 at 4:23:09 PM

naming the old behavior setHTMLUnsafe is what did it for me. security features that require developers to opt in don't work. making the unsafe path feel unsafe does.

by kevincloudsec

2/24/2026 at 4:59:40 PM

Well, the name SetHTML, or let's say:

    .set_html()

Makes objectively more sense than:

    .inner_html()
    .inner_html =
    .set_inner_html()

It is a fairly small thing, but ... really. One day someone should clean up the mess that is JavaScript. Guess it will never happen, but JavaScript has so many strange things ...

I understand that this here is about protection against attacks rather than a better API design, but really - APIs should ideally be as great as possible the moment they are introduced and shown to the public.

by shevy-java

2/24/2026 at 5:02:31 PM

To be pedantic that’s the DOM API, which is exposed to JavaScript.

The DOM API has always felt like, and still does, it was written by people that have never made an API.

by lloydatkinson

2/24/2026 at 6:52:44 PM

I don't think that's pedantic. Seems like a valid objection to me.

So many issues in the client JS world originate from insufficient or bad browser APIs.

by pier25

2/24/2026 at 8:42:38 PM

I don’t really think it’s pedantic it’s just that unless you preface a lot of comments on HN these days, you’ll get a lot of whataboutism and straw man arguments.

by lloydatkinson

2/24/2026 at 6:01:11 PM

Kids in the '90s:

  SQL("select * from user where name = " + name);

Kids in the '20s:

  div.innerHTML = "Hello " + user.name;

by dvh

2/24/2026 at 9:38:40 PM

Kids in the '30s:

  "Summarize this email:  " + email.contents

Prompt injection is just the same problem on a new technology. We didn't learn anything from the 90s.

by Legend2440

2/24/2026 at 7:50:54 PM

And for those who want a better innerHTML, use insertAdjacentHTML https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...

I don’t ever use it with user input, but use it often when building SPA without frameworks

by pyrolistical

2/24/2026 at 6:56:44 PM

Tangential but it's amazing in 2026 browsers still don't ship a native DOM morph/merge API like morphdom or idiomorph.

by pier25

2/24/2026 at 4:14:10 PM

is there any situation where innerHTML would be preferable? I could suppose it might be more performant and so if you were constructing something that was not open to XSS it might theoretically be better (with the usual caveat that people always make mistakes about this kind of thing)

by bryanrasmussen

2/24/2026 at 2:44:43 PM

at what point can we consider the development of "set this element's text/html" to be done?

by dbvn

2/24/2026 at 2:57:32 PM

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

by Aachen

2/24/2026 at 3:07:57 PM

tablenames cannot be parameterized in SQL

https://stackoverflow.com/questions/78516750/parametrize-tab...

by itishappy

2/25/2026 at 1:37:14 AM

What's the benefit over Trusted Types?

by Avamander

2/24/2026 at 1:48:03 PM

A rather deceptive title, given that 'innerHTML' isn't going away.

by antonyh

2/24/2026 at 3:56:49 PM

I think the title is trying to convince you to switch from InnerHTML to SetHTML.

by jandrese

2/24/2026 at 8:02:25 PM

Another solution is just use this at the start of your code:

    delete Element.prototype.innerHTML;

Then assignments to innerHTML do not modify the element's textContent or child node list and assignments to it will not throw an error.

by austin-cheney

2/24/2026 at 5:05:09 PM

My corporate firewall blocks it due to the "hacks" in the subdomain / url. This is silly.

by giancarlostoro

2/24/2026 at 7:59:11 PM

That's why the DNS for hackernews is news.ycombinator.com and not hackernews.org

by ok123456

2/25/2026 at 12:30:29 AM

never even considered that to be honest.

by giancarlostoro

2/24/2026 at 1:59:27 PM

Nice one. Will there be any impact on __dangerouslySetInnerHTML (React)?

by bingemaker

2/24/2026 at 3:31:02 PM

Oh, that's nice-to-have. Good work, Mozilla.

It would close the loop better if you could also use policy to switch off innerHTML in a given page, but definitely a step in the right direction for plain-JavaScript applications.

by shadowgovt

2/24/2026 at 2:07:59 PM

[dead]

by octoclaw

2/24/2026 at 8:38:47 PM

[dead]

by umairnadeem123