Mozilla Hacksに掲載された 「Goodbye innerHTML, Hello setHTML: Stronger XSS Protection in Firefox 148」 を紹介します。
この記事のテーマは、XSS対策として標準化されたSanitizer APIと、Firefox 148でサポートされた setHTML() です。従来よく使われてきた innerHTML は、外部入力やユーザー生成コンテンツを扱う場面で危険なHTMLやイベント属性をDOMへ入れてしまうリスクがあります。setHTML() は、そのHTML挿入のタイミングにサニタイズを組み込むことで、より安全な既定動作を提供しようとするAPIです。
Sanitizer APIが埋めようとしている隙間
記事では、Mozillaが2009年からContent Security Policy（CSP）の標準化にも深く関わってきたことに触れています。CSPは、どのスクリプトや画像、スタイルを読み込んでよいかをブラウザへ伝える強力な防御層です。ただし、既存サイトに導入するには設計変更や継続的な見直しが必要で、Web全体の長い裾野を守るには導入の難しさが残ります。
Sanitizer APIは、そこに別の入口を用意します。危険なHTMLを「無害なHTML」に変換し、DOMへ挿入する前に不要な要素や属性を落とす仕組みです。記事の例では、イベントハンドラ付きの画像要素を含むHTMLを setHTML() で扱うと、危険な部分が取り除かれます。
リンク先から見えた補足
記事内で参照されている MDNのXSS解説 では、XSSは攻撃者のコードを対象サイト自身のコードのように実行させる攻撃として説明されています。ユーザー入力をページに挿入する処理が、適切なエンコードやサニタイズを経ていない場合に問題になります。
HTML Sanitizer API仕様 と MDNのsetHTML()ドキュメント を見ると、APIの狙いは「HTMLを挿入したい」という実務上の需要を否定することではなく、その操作を標準の安全な経路に寄せることだと分かります。さらに Sanitizer API Playground では、どのような入力がどうサニタイズされるかを試せます。
また、CSP と Trusted Types の説明も合わせて読むと、XSS対策は単独のAPIだけで完結するものではないことが見えてきます。CSPは実行できるリソースを制限する防御層、Trusted Typesは危険なHTML挿入箇所をポリシーで管理する仕組み、Sanitizer APIはHTML挿入時の安全な変換を標準化する仕組みとして位置づけられます。
気づき
この記事を読んでの気づきは、セキュリティ機能は「正しく使えば強い」だけでは不十分で、「既存コードから少しずつ置き換えやすい」ことが普及には重要だという点です。CSPのような強力な防御は価値が高い一方、導入コストが大きいと、現実の多くのサイトには届きにくくなります。
setHTML() の方向性は、開発者がすでに行っているHTML挿入という作業を、より安全な標準APIへ移すものです。大規模な設計変更を求めるだけでなく、危険な慣習を安全な既定値へ置き換える道を用意することが、Web全体の底上げにつながるのだと感じました。
読んでおきたい人
ユーザー投稿、コメント、CMS入力、リッチテキスト、外部HTMLのプレビューなどを扱うWeb開発者には特におすすめです。innerHTML を使っている箇所があるプロジェクトでは、今後 setHTML()、Sanitizer API、Trusted Typesをどう組み合わせるかを検討するきっかけになります。
参照元: Goodbye innerHTML, Hello setHTML: Stronger XSS Protection in Firefox 148 – Mozilla Hacks（2026年2月24日公開）
コメントを残す