- innerHTML利用時の安全対策は「便利さと危険性のバランスを取るための設計」です
- innerHTMLが危険になる典型的なパターンをまず理解する
- ステップ1：「innerHTMLは“生HTMLを注入するための危険な道具”」という認識を持つ
- ステップ2：テキストを表示したいだけなら、まずはinnerHTMLを使わない
- ステップ3：「静的テンプレート＋動的データ」のときの安全なinnerHTML利用パターン
- ステップ4：どうしてもinnerHTMLに動的なHTMLを入れたい場合は「サニタイズ」を挟む
- ステップ5：業務で使える「innerHTML安全利用ユーティリティ」を作る
- ステップ6：innerHTMLと他の危険APIの「セット」を意識する
- ステップ7：フレームワーク利用時も「innerHTML相当の機能」に注意する
- ステップ8：innerHTMLとXSSの関係を深く理解しておく
- ステップ9：チームで共有するための「innerHTML利用ルール」をコードとドキュメントに刻む
- まとめ：innerHTML利用時の安全対策は「便利な道具に“安全カバー”を付けるための設計」です
innerHTML利用時の安全対策は「便利さと危険性のバランスを取るための設計」です
業務システムのフロントエンドでは、innerHTML はとても魅力的なAPIです。 一行で複雑なHTMLを差し込めて、テンプレート的な使い方もしやすいからです。
element.innerHTML = "<p>こんにちは</p>";
しかし同時に、innerHTML は DOM Injection や XSS攻撃の入り口になりやすい危険なAPI でもあります。 特に「外部から来た文字列」をそのまま innerHTML に渡すと、一気にリスクが高まります。
ここでは、初心者向けに、
- なぜ
innerHTMLが危険になりうるのか - どんなときに使ってよいのか／ダメなのか
- 安全に使うためのユーティリティと設計
をステップバイステップで解説していきます。
innerHTMLが危険になる典型的なパターンをまず理解する
危険な例1：ユーザー入力をそのままinnerHTMLに入れる
const comment = getUserInputComment(); // ユーザー入力
document.getElementById("comment").innerHTML = comment; // 危険
攻撃者が次のような文字列を入力するとします。
<script>alert('XSS');</script>
すると、ブラウザはこれを「文字列」ではなく 実際の <script> タグとして解釈し、JavaScriptを実行してしまいます。
危険な例2：URLパラメータをそのままinnerHTMLに入れる
const params = new URLSearchParams(location.search);
const msg = params.get("msg");
document.getElementById("message").innerHTML = msg; // 危険
攻撃者は次のようなURLを作れます。
https://example.com/page?msg=<img src=x onerror=alert('XSS')>
これを開くと、 <img src=x onerror=...> がそのままDOMに注入され、 onerror に書かれたJavaScriptが実行されます。
ポイント：innerHTML は「文字列をHTMLとして解釈する」APIであり、 外部入力をそのまま渡すと、攻撃者に「HTMLを書く権限」を渡してしまうことになります。