XSS（クロスサイトスクリプティング）は、他人のブラウザで、攻撃者のスクリプトを動かす攻撃です。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
どう起きる？
たとえばコメント欄に、攻撃者が「スクリプト入りの文字列」を書き込む。サービスがそれをそのまま画面に表示すると、そのページを見た人のブラウザで、そのスクリプトが実行されてしまいます。
結果、Cookie（ログイン状態）を盗まれる、勝手に操作される、などの被害が起きます。
アニメーション『XSSの流れ（仕込み→表示→実行）』を開く
この部分をもっと深く（中級）
XSS は「信頼できない入力が、エスケープされずに HTML・JS・URL へ出力される」ときに成立します。経由する場所で種類が分かれます。
- 反射型 — リクエストに含めた値が、その応答ページにそのまま出る
- 格納型 — 保存された値（コメントなど）が、後で別の利用者の画面に出る
- DOM型 — サーバを介さず、ブラウザ内の JavaScript が値を危険な形で DOM へ書き込む
アニメーション『XSSの流れ（仕込み→表示→実行）』を開く
種類は違っても根本原因は一つ——出力の瞬間に、文脈に合った変換をしていないこと。結果として Cookie（ログイン状態）を盗まれる、勝手に操作される、などの被害が起きます。
どう防ぐ？
- 出力エスケープ — 画面に出すとき、
<や>などを「ただの文字」に変換する。これでスクリプトとして動かない - 文脈に合わせる — HTML・属性・URL・JS の中で、必要なエスケープが違う
- CSP（コンテンツセキュリティポリシー） — そもそも許可していないスクリプトの実行を、ブラウザ側で止める
ポイントは「入力を消すのではなく、出力を安全にする」こと。データは受け取ってよく、出す瞬間に無害化します。
この部分をもっと深く（中級）
守りは出力側に置きます。
- 文脈別の出力エスケープ — HTML本文・HTML属性・JS・URL では必要な変換が違う。出す先に合った規則で「ただの文字」に変換する
- CSP（コンテンツセキュリティポリシー） — スクリプトの出所を制限し、許可していないスクリプトの実行をブラウザ側で止める
- HttpOnly Cookie — JavaScript から Cookie を読めなくし、万一スクリプトが動いても盗ませない
ポイントは「入力の混入ではなく、出力の扱いで防ぐ」こと。データは受け取ってよく、出す瞬間に無害化します。
登場人物メモ:
- ※1 出力文脈 — 値を出す先（HTML・属性・JS・URL）。文脈ごとに変換規則が違う
- ※2 CSP — スクリプトの出所を制限し、想定外の実行を止める仕組み
⚠️ 気をつける
- 入力検証だけに頼る — 保存された値が別の画面で出るときに漏れる（格納型XSS）
- エスケープの文脈ミス — HTML用のエスケープをURLやJSにそのまま使う
- innerHTML の乱用 — 受け取った文字列をそのままHTMLとして挿入しない
この部分をもっと深く（中級）
- 入力検証だけに頼る — 保存された値が別の画面で出るときに漏れる（格納型XSS）
- エスケープの文脈ミス — HTML用のエスケープを URL や JS にそのまま使う
- innerHTML の乱用 — 受け取った文字列をそのまま HTML として挿入しない
- CSPを免罪符にする — CSP は補助。エスケープの代わりにはならない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. XSSの基本的な防ぎ方は？
問2. XSS（クロスサイトスクリプティング）が悪用するのは？
問3. XSS の正式名称をカタカナで答えてください（クロスサイト…）。
問4. XSSが成功したときに起きやすい代表的な被害はどれ？
問5. 出力時にエスケープすると、`<script>` のような文字列はどうなる？
問6. XSS対策の考え方として正しいのはどれ？
問7. そもそも許可していないスクリプトの実行を、ブラウザ側で止める仕組みはどれ？
問8. 保存された値が後で別の利用者の画面に出て発火するXSSの種類を何という（漢字＋型）？