【テクニカル・上級編】 JSXにおけるエスケープ処理 – React実践ガイド

Reactにおける「安全」という名の聖域：JSXの自動エスケープとDOM操作の深淵

Reactというフレームワークが、なぜこれほどまでに世界中の大規模アプリケーションの基盤として選ばれ続けているのか。その理由の一つに、「デフォルトで安全である」という設計思想があります。

我々のようなフロントエンドの現場に身を置く者にとって、DOMを直接触ることは「禁忌」に近い。かつてjQuery時代に経験した、あの泥沼のようなXSS（クロスサイトスクリプティング）の記憶を覚えている諸君なら、ReactがJSXの中でデフォルトで施している「自動エスケープ」が、どれほど偉大な発明か理解できるはずです。

今日は、その恩恵を再確認しつつ、なぜ我々が`dangerouslySetInnerHTML`という「毒」を扱う際に、なぜそれほどまでに神経質にならねばならないのか。その深層を紐解いていきましょう。

—

1. JSXという「安全装置」のメカニズム

ReactのJSXは、単なるHTMLのテンプレートではありません。`React.createElement`へとトランスパイルされる過程で、ReactはJSX内で記述された変数を文字列として処理します。

// Reactはレンダリング前に全ての変数を文字列に変換（Stringification）する
const userInput = ““;

// JSXはこれを「実行可能なコード」ではなく「単なるテキストノード」として扱う
// 結果としてブラウザには という文字列がそのまま表示されるだけだ
const SafeComponent = () =>

;

この挙動こそが、Reactにおける最大の防御壁です。ReactはDOMツリーに挿入する前に、値を安全な文字列へと変換します。ブラウザのレンダリングエンジンに対して「これはただの文字だ、決して実行するな」と強い制約をかけているわけです。

—

2. `dangerouslySetInnerHTML`：その名に込められた警告

名前からして危険な香りが漂うこのプロパティ。Reactの設計チームが、あえて「危険（dangerously）」という形容詞を冠したのは、「お前が今から何をやろうとしているのか、本当に理解しているのか？」という開発者への強烈な問いかけです。

CMSから取得したHTMLや、リッチテキストエディタの出力など、どうしても生HTMLを注入しなければならない場面は存在します。しかし、安易にこれを使うことは、Reactの防御壁を自ら取り壊す行為に他なりません。

脆弱性を生まないための「聖域」の作り方

もし、どうしてもHTMLをレンダリングする必要があるならば、必ずサニタイズ（無害化）をセットで行う必要があります。信頼できない入力をそのまま流し込むのは、サーバーサイドで`eval()`を実行するのと同じくらい無謀です。

import DOMPurify from ‘dompurify’; // 業界標準のサニタイズライブラリ

const RichTextComponent = ({ htmlContent }) => {
// DOMPurify.sanitize は有害なスクリプトタグや属性を除去する
// 処理後の安全なHTMLのみを dangerouslySetInnerHTML に渡す
const sanitizedHtml = DOMPurify.sanitize(htmlContent);

return (