IdeaWell

Project ideas from Hacker News discussions.

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

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Three dominant themes in the discussion

Theme Key points Representative quotes
1. Safety & the ambiguity of “safe” sanitization Developers worry that the new API mixes “safe” and “unsafe” methods, that the term safe is vague, and that the default configuration still allows markup that could be abused. • entuno: “This kind of thing always makes me nervous… it’s not at all clear which is which from the names.”
• jncraton: “You are right that the concept of ‘safe’ is nebulous, but the goal here is specifically to be XSS‑safe.”
• embedding‑shape: “How exactly, given that setHTML sanitizes the input? If you don’t want any HTML tags, can you configure that?”
2. Tooling, adoption, and browser support The community discusses how to adopt the API—via linters, polyfills, or AI‑assisted refactoring—and notes that widespread browser support is still pending. • thenewnewguy: “If you want to adopt this in your project, you can add a linter that explicitly bans innerHTML.”
• simonw: “It looks like it will be a while before browser support is widely distributed enough to rely on it.”
• noduerme: “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.”
3. Practical use cases & trade‑offs Users weigh the benefits of allowing limited markup (e.g., markdown) against the risk of footguns and the fact that the API still permits arbitrary non‑script tags. • cogman10: “The main case I can think of is wanting some forum functionality… you could take the HTML generated from the markdown and further lock it down.”
• Aachen: “Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even <style> rules).”
• cogman10: “Seems like this has a bunch of footguns… especially if you use the ‘remove’ sanitizer API.”

These themes capture the community’s concerns about safety, the practical steps needed for adoption, and the real‑world trade‑offs developers face when moving from innerHTML to the new sanitization API.

🚀 Project Ideas

Generating project ideas…

SafeDOM Linter

Summary

  • A static‑analysis plugin that flags all unsafe DOM APIs (innerHTML, setHTMLUnsafe, etc.) and suggests safe replacements (textContent, setHTML with a safe config).
  • Provides an automated migration script and a clear naming convention guide to help teams refactor legacy codebases.

Details

Key Value
Target Audience Front‑end developers, QA teams, and code‑reviewers working on web apps.
Core Feature Detects unsafe DOM manipulation, auto‑generates refactor suggestions, and enforces a policy file.
Tech Stack TypeScript, ESLint, Babel plugin, VS Code extension, CI integration (GitHub Actions).
Difficulty Medium
Monetization Revenue‑ready: $49/month per team (tiered for open‑source).

Notes

  • HN commenters complain about “mix of methods where you can pass arbitrary user input” and “not clear which is safe.” This tool gives a single source of truth.
  • The migration script addresses the “mythical refactor” frustration and can be discussed in code‑review threads.

AutoSanitize Proxy

Summary

  • A lightweight runtime library that intercepts all DOM writes, automatically sanitizes them using the browser’s Sanitizer API when available, or falls back to DOMPurify.
  • Exposes a simple API (safeSetHTML, safeInnerText) and a configuration panel for allowed tags/attributes.

Details

Key Value
Target Audience Web developers, CMS vendors, and front‑end teams needing quick XSS protection.
Core Feature Runtime interception of unsafe DOM writes, automatic sanitization, and a UI for policy tweaking.
Tech Stack JavaScript, Web Components, Service Workers, optional WebAssembly for performance.
Difficulty Medium
Monetization Hobby (open‑source) with optional paid support.

Notes

  • Addresses the “innerHTML vs setHTML” debate by providing a drop‑in replacement that is safe by default.
  • The UI for policy tweaking satisfies commenters who want “configurable safe defaults” and can spark discussion on best‑practice policies.

SecureRender API

Summary

  • A cloud service that accepts raw user content and returns fully sanitized HTML according to a user‑defined policy, optionally enhanced with AI‑based malicious pattern detection.
  • Offers SDKs for popular frameworks and a REST endpoint for CMS integration.

Details

Key Value
Target Audience CMS vendors, SaaS platforms, and developers who need server‑side sanitization.
Core Feature Policy‑driven sanitization, AI threat detection, audit logs, and CDN‑ready delivery.
Tech Stack Go (backend), TensorFlow Lite (AI), Docker, Kubernetes, GraphQL API.
Difficulty High
Monetization Revenue‑ready: $0.01 per 1,000 characters + $29/month for premium features.

Notes

  • Solves the “no safe defaults” frustration by providing a single, auditable source of truth for sanitization.
  • The AI layer responds to the comment about “some sanitization is better than none” and can be a topic for security‑focused HN discussions.

Read Later