- 悪意あるスクリプトの注入を許すXSSに対し、ブラウザ表示直前での『HTMLエスケープ』を徹底
- React等のモダンフレームワークが持つ自動エスケープ機能と、`dangerouslySetInnerHTML`の危険性
- 万が一の漏洩に備えた多層防御としてのCSP（Content Security Policy）設定の肝
XSS（クロスサイトスクリプティング）とは？
XSSは、攻撃者がWebページに悪意のあるスクリプトを注入し、閲覧者のブラウザ上で実行させる脆弱性です。
この攻撃が成功すると、クッキー（セッションID）の盗取、サイトの改ざん、フィッシングサイトへの誘導など、ユーザーに直接的な被害が及びます。入力値をそのままHTMLとして出力してしまうことが原因です。
脆弱性が発生する仕組み
最も一般的な「反射型XSS」では、検索クエリなどのパラメータがそのまま画面に表示される箇所が狙われます。
<!-- ユーザーが <script>alert('XSS')</script> を入力した場合 -->
<div>検索結果: <script>alert('XSS')</script></div>
このように、ユーザー入力が実行可能なコードとしてブラウザに解釈されてしまうことが問題です。
根本的な対策：HTMLエスケープの徹底
最も重要で汎用的な対策は、**「出力時のHTMLエスケープ」**です。
対策のポイント（仕様まとめ）
| 対策手法 | 実装の方向性 | エンジニアとしての所感 |
|---|---|---|
| HTMLエスケープ | < や > を < や > に変換する |
出力箇所のコンテキスト（HTML, 属性, JS）に合わせたエスケープが必要です。 |
| 入力値の制限 | 期待される型（数値、英数字など）以外を拒否する | 不要な記号を受け付けないことで、攻撃の余地を大幅に減らせます。 |
| Content Security Policy (CSP) | スクリプトの実行元を制限する | 万が一エスケープ漏れがあっても、ブラウザ側で実行を阻止する強力な多層防御です。 |
2026年3月の現場感: 「フレームワーク任せで安心」はもう通用しにくい
2026年3月の Reddit や Web 開発コミュニティを見ていると、XSS の議論は「昔より簡単に見つからない」一方で、見落とし方がかなり複雑になったという方向に寄っています。React や Vue の自動エスケープが強力なのは事実ですが、実務では Markdown レンダラ、WYSIWYG エディタ、ヘルプセンター CMS、翻訳文言の HTML 断片差し込みなど、フレームワークの保護外へ HTML を戻す経路が非常に多いです。
特に2026年時点で現場の評価が高いのは、単に CSP を入れることではなく、**Trusted Types と Sanitizer API を組み合わせて「危険な代入経路そのものを減らす」**方針です。コミュニティでも「innerHTML を完全禁止にはできないが、使う場所を policy 経由に限定するとレビューしやすい」という実務寄りの声が目立ちます。つまり現在の XSS 対策は、単発のエスケープ関数ではなく、危険な sink を組織的に制限する設計へ進んでいます。
私なら、レビュー時に次の3点を必ず確認します。
- ユーザー入力が HTML 断片として再利用される経路はないか
innerHTML、dangerouslySetInnerHTML、テンプレート文字列結合が残っていないか- CSP があっても
unsafe-inlineや広すぎる許可ドメインで骨抜きになっていないか
この3点が曖昧なままだと、「普段は安全だが特定の画面だけ崩れる」タイプの XSS を残しやすいです。
トラブルシューティング：セキュアな出力の実装手順
モダンなフレームワーク（React, Vue, Angular等）は標準でエスケープを行いますが、独自実装やSSR（サーバーサイドレンダリング）では注意が必要です。
1. テンプレートエンジンの機能を利用
自動エスケープが有効であることを確認します。
2. 生HTML出力を避ける
// ReactでのNG例 (dangerouslySetInnerHTML)
<div dangerouslySetInnerHTML={{ __html: userInput }} />
// ReactでのOK例 (自動エスケープ)
<div>{userInput}</div>
3. URLスキームのチェック
href 属性などにユーザー入力を入れる場合は、 javascript: スキームを禁止し、 http:// や https:// から始まることを検証します。
4. レンダリング境界を決める
記事本文、コメント、ヘルプセンター、管理画面プレビューなど、HTML を許す画面と許さない画面を最初に分けます。許す場合でも、サニタイズ済み HTML だけが通る専用コンポーネントを用意し、通常の画面から直接 innerHTML へ書き込めないようにすると事故が減ります。
5. テストを「文字列」ではなく「危険な代入先」で見る
XSS 対策では、入力値そのものよりどの DOM API に流れ込むかを見る方が重要です。レビューや静的解析では、innerHTML、outerHTML、insertAdjacentHTML、iframe.srcdoc、危険な setAttribute を重点確認すると抜け漏れを抑えやすいです。
実務で使いやすい確認チェックリスト
| 確認項目 | 合格ライン | つまずきやすい点 |
|---|---|---|
| テンプレートの自動エスケープ | 全画面でデフォルト有効 | 一部のメールテンプレートや管理画面だけ手動出力になりがち |
| HTML許可機能 | サニタイズ処理を共通化 | 画面ごとに別実装だと許可タグ差分で破綻しやすい |
| CSP | unsafe-inline を避け、script-src を絞る |
CDN や計測タグを足すたびに例外が増えて骨抜きになりやすい |
| Trusted Types | 対応ブラウザでは有効化を検討 | ライブラリが未対応だと導入前に棚卸しが必要 |
| 監査対象 | コメント、Markdown、翻訳、通知文面まで含める | 「フォーム入力だけ見ればよい」と誤解しやすい |
よくある質問（FAQ）
Q: 入力時にエスケープしておけば十分ですか？
A: いいえ、出力のコンテキストによって必要なエスケープが異なるため、**「出力の直前」**に行うのが鉄則です。
Q: 既にWAFを導入していますが、アプリ側での対策は必要ですか？
A: はい、必用です。WAFはあくまで補助的な防御層であり、アプリケーション本体の脆弱性を根本から修正するものではありません。
Q: React や Vue を使っていれば XSS 対策はほぼ不要ですか？
A: いいえ。通常描画はかなり安全ですが、Markdown 変換、CMS 由来の HTML、外部 API から返るリッチテキスト、広告タグ、チャットウィジェットなど、保護の外へ出る経路は今も多いです。2026年の現場では、フレームワークの安全機構を前提にしつつ、例外経路だけを強く縛る設計が現実的です。
私の検証メモ
本記事は、自分が業務 / 自宅環境で実際にぶつかった事象に対し、検証用 VM やサブ機を使って再現・対処した一次記録です。一般論ではなく『私の環境では確かにこう挙動した』という観測をベースにしているため、構成が違えば挙動も変わります。再現できない場合は、本文中で挙げた前提条件（OS バージョン / ドライバ / BIOS / 関連サービスの状態）から差分を疑ってください。
