Hacker News
Firefox 148 is the first browser to implement the standardized Sanitizer API, introducing the setHTML method to automatically neutralize malicious code and provide a safer alternative to innerHTML for web developers.
AI 生成摘要
Firefox 148 是首個實作標準化 Sanitizer API 的瀏覽器，透過引入 setHTML 方法自動過濾惡意代碼，為網頁開發者提供一個比 innerHTML 更安全且能預防 XSS 攻擊的替代方案。
隨著跨站腳本攻擊（XSS）長期佔據網頁安全威脅的前三名，Mozilla 宣布在 Firefox 148 中正式支援標準化的 Sanitizer API。這項新功能透過 setHTML() 方法，讓開發者在將不受信任的 HTML 內容插入 DOM 之前，能由瀏覽器原生進行清理與過濾，旨在取代容易產生安全漏洞的傳統 innerHTML 賦值方式。
Hacker News 社群對於這項更新展現了複雜的情緒，討論核心圍繞在 API 命名的直觀性、遷移成本以及原生清理機制的安全性。部分開發者對 API 的命名表達了憂慮，認為 setHTML() 雖然標榜安全，但這種命名方式並未在字面上明確區分「安全」與「危險」的操作。他們擔心在現有的開發環境中，當安全與不安全的方法混雜使用時，開發者可能難以一眼辨識出潛在的風險。雖然有意見指出，理想的開發模式應該是全面淘汰 innerHTML 並改用 setHTML()，或在需要舊有行為時使用 setHTMLUnsafe，但社群中不乏現實主義者認為，這種「神話般的重構」在大型既有專案中幾乎不可能完全實現，網頁標準往往只能不斷堆疊新方法，而無法真正移除舊有的危險工具。
在安全性方面，許多討論聚焦於「原生清理」相對於第三方函式庫（如 DOMPurify）的優勢。支持者指出，原生 Sanitizer API 最強大的地方在於它直接使用瀏覽器本身的 HTML 解析器。過去許多 XSS 繞過攻擊是發生在第三方清理工具與瀏覽器解析邏輯不一致的縫隙中，當清理與渲染共用同一個解析引擎時，變異型 XSS 攻擊將無所遁形。然而，也有保守派認為「安全」是一個模糊的概念，過度依賴瀏覽器自動處理可能會讓開發者掉以輕心。對此，部分開發者堅持最穩健的做法仍是盡可能使用 innerText，僅在絕對必要時才考慮 HTML 插入，並建議將此 API 與 Trusted Types 結合使用，以建立更嚴密的防禦體系。
此外，瀏覽器的相容性也是社群關注的焦點。儘管 Firefox 率先支援，但目前其他主流瀏覽器的跟進進度仍影響著開發者的採用意願。有留言提醒，這類涉及底層安全邏輯的 API 不適合使用 Polyfill 填充工具，因為其安全性高度依賴瀏覽器對跨站腳本規則的內建評估能力，而非單純的功能模擬。對於使用 React 等框架的開發者來說，這項標準是否會進一步影響如 dangerouslySetInnerHTML 等框架特有的方法，也是後續值得觀察的技術演進方向。