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

Original Article ↗ Hacker News Discussion ↗

Concerns about mixed “safe” and “unsafe” APIs

  • People worry about having both innerHTML and setHTML/setHTMLUnsafe: it’s unclear from names alone which accept untrusted input safely.
  • Some argue suffixes like Unsafe help clarify intent; others say they create a false sense of security if “safe” variants aren’t explicitly labeled.
  • There’s pessimism that large codebases will ever fully refactor away from innerHTML; linting and project-level bans are seen as the realistic path.

Skepticism about HTML sanitization and “safety”

  • Several commenters distrust generic “HTML sanitizers” due to a long history of bypasses and the context‑dependent nature of “safe.”
  • One strong view: HTML sanitization is fundamentally unsolvable in the general case; the only reliable rule is “treat untrusted input as text” (e.g., textContent).
  • Others counter that a browser‑integrated, allowlist‑based Sanitizer is still a big improvement over ad‑hoc userland libraries.

What setHTML actually protects against

  • Consensus that setHTML is aimed specifically at preventing XSS / script execution, not all classes of injection.
  • Concern that the default config still allows arbitrary markup (e.g., <h1>, <br>, possibly <style>), enabling CSS‑based attacks or visual spoofing.
  • Some see it as “defense in depth” layered on top of markdown renderers or server‑side sanitizers, rather than a primary security control.

Alternatives and best practices

  • Many recommend continuing to use textContent / innerText for untrusted user data, and DOM APIs (createElement, appendChild) for structure.
  • Trusted Types and CSP (require-trusted-types-for 'script') are highlighted as stronger global protections.
  • Linters or even redefining/removing innerHTML on Element.prototype are mentioned as ways to ban dangerous patterns locally.

Use cases and value of setHTML

  • Proposed good fits: rich‑text editors, forums, markdown output, “client‑side includes” where some tags are allowed but scripting must be blocked.
  • Critics argue setHTML is “in between” and unnecessary: you either allow full markup (innerHTML) or separate code/data strictly (textContent + DOM).

Ecosystem, tooling, and broader issues

  • Browser support is still limited; polyfills are viewed as risky for this API because security depends on the browser’s parser.
  • Some suggest AI for large‑scale refactors away from innerHTML, though others point out AI’s tendency to emit deprecated patterns.
  • Complaints about messy DOM API design, lack of native DOM morph/merge, absence of a robust sandbox element, and ongoing fragmentation across browsers.