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

https://hacks.mozilla.org/2026/02/goodbye-innerhtml-hello-sethtml-stronger-xss-protection-in-firefox-148/

105•todsacerdoti•1h ago

Comments

entuno•1h ago

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

voxic11•1h ago

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.

post-it•53m ago

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

noduerme•47m ago

Finally, a good use case for AI.

josefx•39m ago

Wouldn't AI be trained on data using innerHTML?

Aachen•19m ago

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

charcircuit•18m ago

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

stvltvs•17m ago

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

fragmede•15m ago

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.

Aachen•21m ago

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

charcircuit•19m ago

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

Vinnl•36m ago

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

thunderfork•21m ago

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

delaminator•19m ago

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

thenewnewguy•36m ago

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.

bulbar•18m ago

It for sure happens for drop in replacements.

croes•32m ago

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

orf•16m ago

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

tbrownaw•6m ago

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

reddalo•14m ago

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

extraduder_ire•3m ago

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.

DoctorOW•55m ago

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

post-it•55m ago

realSetSafeHTML()

jncraton•52m ago

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

snowhale•50m ago

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.

pornel•2m ago

[delayed]

noduerme•47m ago

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.

simonw•1h ago

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

jraph•1h ago

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.

tuyiown•1h ago

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.

antonyh•1h ago

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

tuyiown•1h ago

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.

bingemaker•55m ago

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

Aachen•32m ago

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?

embedding-shape•29m ago

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

Aachen•25m ago

> 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

embedding-shape•23m ago

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

Aachen•6m ago

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"

cogman10•23m ago

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

Aachen•14m ago

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

byproxy•13m ago

> 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

cogman10•28m ago

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.

evilpie•7m ago

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.

dbvn•10m ago

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

Urban sprawl is a tragedy of the commons (2021)

The road to hell is paved with asphalt (2024)

Show HN: TypeGraph – Type-safe graphs on Postgres/SQLite (no graph DB required)

Trump Fake Electors Plot

Tech Turned Against Women

Proof that at most one of e*pi and e+pi can be rational

Huntarr – Your passwords and your ARR stack's API keys are exposed

Bareclaw: Claude Code Is All You Need

Show HN: Bruce – AI signal radar for Reddit/HN that learns what matters to you

The Prisoner's Dilemma: Why Rational Choices Can Lead to the Worst Outcomes

We Shouldn't Fight Automation

First-of-a-kind stem-cell therapies set for approval in Japan

Bhutan's crypto experiment shows how hard digital money is in the real world

AI 2027 and the Shrinking of Understanding

OpenClaw Meets Healthcare

I'm a 15-year-old girl. Here's the vile misogyny I face daily on social media

Female Reproductive Tract-on-a-Chip for selecting healthier sperm

Covert DEI Design Techniques for Earthly Survival in Hostile Contexts

LFM2-24B-A2B: Scaling Up the LFM2 Architecture

SQL history lesson with Oracle V2

Metabolism, not cells or genetics, may have begun life on Earth

Walkman.land

Show HN: DoNotify – Google Calendar reminders as phone calls(not notifications)

There's software, and then there's promptware

EDRi Open Letter: We say no to Big Tech mass snooping on our messages

Tim Cook Warned by CIA That China Could Move on Taiwan by 2027

IBM stock tumbles 10% after Anthropic launches COBOL AI tool

Data center builders thought farmers would willingly sell land, learn otherwise

Towards a Science of AI Agent Reliability

How we made Docker builds 193x faster across AI agent sessions