Webの守りの土台が、入力の検証。「外から来た値を、そのまま使わずに確かめる」ことです。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
なぜ必要？
ブラウザから届く値・URLのパラメータ・アップロードされるファイル——これらは攻撃者が自由に作れるものです。そのまま使うと、XSSやSQLインジェクションなどの穴になります。だから、まず疑って確かめます。
この部分をもっと深く（中級）
ブラウザから届く値・URLのパラメータ・アップロードファイル・APIのリクエストボディ——これらはすべて信頼境界の外から来ます。攻撃者が自由に作れる以上、そのまま処理へ流すと XSS や SQLインジェクションの入口になります。
ポイントは、検証は信頼境界を越える所で行うこと。外の値が内側のロジックへ入る手前に「関所」を置きます。
どう確かめる？
- 型 — 数値のはずが文字列でないか
- 範囲・長さ — 想定の範囲に収まっているか（年齢が -1 や 9999 でないか）
- 形式 — メールの形、日付の形など
- 許可リスト — 「許可するものだけ通す」（危ないものを列挙するより安全）
入力検証は、外から来た値を確かめる「関所」です。通ったものだけ処理へ進み、怪しいものは弾きます。
アニメーション『入力検証＝関所』を開く
そして最重要は、サーバ側で必ずやること。フロントのチェックは利用者への親切であって、防御ではありません。
この部分をもっと深く（中級）
検証の観点を、緩い順ではなく絞り込む順に重ねます。
- 型 — 数値・真偽・日付など、期待する型か
- 長さ — 上限・下限。極端に長い入力はそれ自体が攻撃の兆候
- 範囲 — 数値や日付が想定の区間に収まるか
- 形式 — メール・電話・IDなど、決まった形に合うか
- 許可リスト ＞ 拒否リスト — 最後は「通してよいものだけ通す」に寄せる
アニメーション『入力検証＝関所』を開く
正規化を先に、検証を後に。 全角／半角、大文字／小文字、Unicodeの合成形などの表記ゆれを揃えてから検証します。順序を逆にすると、検証後に別の形へ化けて許可リストをすり抜けられます。
そして最重要は、サーバ側で必ずやること。フロントの検証は UX 補助（入力ミスへの親切）であって、防御ではありません。攻撃者はフロントを無視して直接サーバへ送れます。
登場人物メモ:
- ※1 信頼境界 — 信用できる領域と、できない領域の境目。検証はこの境界で行う
- ※2 正規化 — 表記ゆれを揃え、比較・検証できる形にそろえる前処理
⚠️ 気をつける
- フロントだけで検証 — 直接サーバへ送られたら素通り
- 拒否リスト頼み — 危ないものを列挙する方式は抜けが出る
- 検証と無害化の混同 — 検証（弾く）と、出力時のエスケープ（無害化）は別の対策。両方要る
この部分をもっと深く（中級）
- フロントだけで検証 — 直接サーバへ送られたら素通り。サーバで必ず再検証
- 拒否リスト頼み — 危ないものを列挙する方式は抜けが出る。許可リストへ寄せる
- 正規化忘れ・順序ミス — 検証後に化ける表記ゆれをすり抜けられる
- 検証と無害化の混同 — 入口の検証だけで安心し、出口のエスケープを省く
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 入力の検証を「サーバ側でも必ず」やるべき理由は？
問2. 入力検証で安全側なのは？
問3. 入力検証は「関所」に例えられます。関所の役目に近いのはどれ？
問4. 「年齢が -1 や 9999 でないか」を確かめるのは、どの観点のチェック？
問5. 「検証（弾く）」と「出力時のエスケープ（無害化）」の関係で正しいのはどれ？
問6. 外から来た値を「まず疑う」のはなぜ？
問7. 「許可するものだけを通し、それ以外は弾く」検証方式を、何リストと呼ぶ？
問8. 入力の検証は、フロント（手元）ではなく必ずどこ側で行うべき？