先日、Chrome 146 の正式版がリリースされましたね。DevTools の改善や Web Platform の更新など、開発者向けの変更もいくつか含まれていました。その中で少し気になったのが Sanitizer API です。
HTML を文字列として扱う処理は、Web アプリケーションではよく書かれてきました。コメント機能や投稿フォームなど、ユーザーが入力した内容を画面に表示する場面は少なくありません。ただ、その一方でセキュリティ上のリスクも伴います。例えば、ユーザー入力の中にスクリプトが含まれていた場合、それがそのまま実行されてしまう可能性があります。こうした問題は XSS（クロスサイトスクリプティング） と呼ばれ、Web アプリケーションではよく知られている攻撃のひとつです。
こうした問題を避けるため、これまでは HTML を表示する前に 危険な要素や属性を取り除く処理を行うのが一般的でした。この処理をサニタイズ（sanitize） と呼びます。そのサニタイズ処理をブラウザ標準の API として提供するための仕組みが、Sanitizer API です。
Sanitizer API ってなんぞや？
先ほども少し触れたように、HTML をサニタイズ（無毒化）して DOM に挿入するための Web API です。例えば、ユーザーが入力した HTML を表示する場合、次のように書くことができます。
const sanitizer = new Sanitizer();
element.setHTML(userInput, { sanitizer });
このときブラウザは、<script> 要素やイベントハンドラ属性など、スクリプト実行につながる可能性のある要素を取り除いたうえで DOM に挿入します。つまり、次のように直接 HTML を挿入する方法よりも、安全に扱える可能性があります。
element.innerHTML = userInput;
innerHTML 自体は便利な API ですが、ユーザー入力をそのまま挿入すると XSS の原因になることがあります。Sanitizer API は、そうした状況を避けるためのより安全な選択肢として設計されています。
なぜこの API が必要だったのか
HTML のサニタイズ自体は、決して新しい考え方ではありません。これまでも多くのアプリケーションでは、DOMPurify や sanitize-html といったライブラリを使って HTML をサニタイズしてきました。つまり、安全に HTML を扱うための方法は存在していたわけです。ただ、それらはあくまで外部ライブラリでした。
ブラウザ自体が HTML を解析して DOM を作る仕組みを持っているにもかかわらず、
サニタイズ処理は JavaScript のライブラリに頼るしかない、という状況が長く続いていたとも言えます。Sanitizer API は、その処理をブラウザの標準機能として提供しようとする試みと考えることもできそうです。
便利そうに見えるけど、任せれば良いわけではない
Sanitizer API は、HTML を扱うときの安全性を高めてくれる API です。ただ、これだけですべての XSS を防げるわけではありません。例えば、次のような挙動は設定に依存します。
- どの要素を許可するか
- どの属性を残すか
また、HTML を文字列として扱う設計そのものが適切なのか、という点も状況によって変わってきます。Sanitizer API は便利な API ですが、設計自体が持つリスクが消えるわけではありません。便利な API が増えてきたからこそ、HTML をどのように扱うのかという基本も、あらためて意識しておきたいところです。
