我々セキュリティプロフェッショナルにとって、インジェクション攻撃は常に最前線で対峙すべき脅威であり続けています。特にウェブアプリケーションにおいて、ユーザーからの信頼できない入力がHTMLとして処理される場面は枚挙にいとまがなく、その隙を突くクロスサイトスクリプティング（XSS）は、攻撃者にクライアントサイドでの任意コード実行を許す、極めて危険な脆弱性です。
世の中には様々なサニタイズライブラリが存在しますが、DOMPurifyはその堅牢性と信頼性から、多くのプロダクション環境で採用されています。しかし、「ライブラリを使えば安心」という安易な思考は、我々が最も警戒すべき「盲点」を生み出します。本稿では、DOMPurifyを単なるツールとしてではなく、多層防御アーキテクチャの一部として最大限に活用するための、深い洞察と実践的な設定戦略を提示します。
DOMPurifyの本質と、その防衛メカニズム
DOMPurifyは、信頼できないHTML、SVG、MathMLの文字列を受け取り、潜在的に悪意のあるコードを除去して、安全なHTML文字列を返すためのライブラリです。その内部動作は、正規表現ベースのサニタイザーとは一線を画します。DOMPurifyは、ブラウザのDOMパーサーを内部的に利用し、実際にDOMツリーを構築します。そして、構築されたDOMツリーを走査し、ホワイトリスト方式で定義された安全なタグや属性のみを許可し、それ以外を削除または無害化します。
この「DOMパーサーを利用する」という点が極めて重要です。なぜなら、攻撃者はブラウザのHTMLパーサーの挙動の差異や、エッジケースを突いてXSSペイロードを仕掛けます。正規表現ベースのサニタイザーでは、これらのパーシングの複雑性を完全に模倣することは困難であり、結果として正規表現の漏れや誤動作によるバイパスを許しがちです。DOMPurifyは、ブラウザ自身と同じロジックでDOMを解釈するため、この種のパーシングロジックの差異に起因する脆弱性を効果的に軽減できるのです。
しかし、この堅牢なメカニズムをもってしても、設定の誤りや、多層防御の欠如は、容易に防御壁を崩壊させます。
DOMPurifyの安全な設定とベストプラクティス
DOMPurifyのデフォルト設定は非常にセキュアですが、アプリケーションの要件によっては、デフォルトでは許可されない特定のHTML要素や属性を許容する必要が生じます。このカスタマイズこそが、攻撃者が狙う「設定ミス」の温床となり得ます。
1. デフォルト設定の理解と最小限のカスタマイズ
まず、DOMPurify.sanitize() を引数なしで実行した場合、どのような要素や属性が許可されるのかを理解することが出発点です。基本的には、テキスト装飾（, , ）、リスト（
- ,
,
）、リンク（![]()
ALLOW_DATA_ATTR: false を設定することで、これを禁止できます。
4. SVG/MathML プロファイルの理解と制御
DOMPurifyは、HTMLだけでなくSVGとMathMLのサニタイズもサポートしています。これらのXMLベースのマークアップ言語は、独自のスクリプト実行メカニズムやイベントハンドラを持っており、XSSの温床となり得ます。
デフォルトでは、HTMLプロファイルが有効化され、SVGとMathMLは無効化されています。もしユーザーがSVGやMathMLを投稿する可能性がある場合、USE_PROFILESオプションでこれらを有効にする必要があります。しかし、これを行う際は、それぞれの仕様に存在する攻撃ベクトルを深く理解し、適切なホワイトリストを構築しなければなりません。
// SVGを許可する場合の例（極めて慎重に行うべき）
const cleanSvg = DOMPurify.sanitize(dirtySvg, {
USE_PROFILES: { svg: true } // SVGプロファイルを有効化
// さらに、FORBID_TAGS や FORBID_ATTR でSVG固有の危険な要素/属性を禁止する
// 例:
コメント