前回の続きと、この講義の役割
前回のJ-05では、全ルート共通の処理を挟むミドルウェアを学びました。今回は、その共通処理の中でも省略できない検証を、ハンドラーの入口でどう行うかを扱います。ここは、以前H-05で予告した「防御」の本体にあたる回です。画面側の親切な検証と、サーバー側の防御の検証は役割が違う、という話を、いよいよこの講義で総まとめしていきます。
このスライドのポイント
- 前回J-05: 全ルート共通の処理を挟むミドルウェア
- 今回: 省略できない検証を、ハンドラーの入口でどう行うか
- ここはH-05で予告した「防御」の本体にあたる回
- 画面側の検証とサーバー側の検証の役割の違いを、この講義で総まとめする
信頼境界と検証6点セット
信頼境界とは、ここから内側は検証済みのデータしか通さない、という線のことです。サーバーの入口が、その境界にあたります。境界で行う検証は6点あります。一つ目は型、数値であるべき項目が数値か。二つ目は形式、日付やメールの形が正しいか。三つ目は長さ。四つ目は範囲、たとえばマイナスの金額を弾きます。五つ目は権限、その人がしてよい操作か。詳しくはカテゴリQで扱います。六つ目は存在確認、指定されたIDが実在するかです。この6点が防御の中身です。
このスライドのポイント
- 信頼境界＝ここから内側は検証済みのデータしか通さない、という線
- サーバーの入口が、その境界にあたる
- 検証6点: ①型 ②形式 ③長さ ④範囲 ⑤権限 ⑥存在確認
- 権限の詳細はカテゴリQ、保存の詳細はカテゴリLで扱う
- H-05で予告した「防御」の本体がこの6点
なぜサーバー側の検証が必要か
検証を省くと、何が起きるでしょうか。よくある事故は、「画面側で検証済みだから」と考えて、サーバー側の検証を省いたコードを、そのまま通してしまうことです。しかし、D-03で見たリクエストは、画面を経由せず直接送れます。つまり、道具を使えば、画面の検証を回避した不正なデータを、いくらでもサーバーへ送れるのです。この事実が腹に落ちていないと、守りの薄いコードを見ても危険だと気づけません。
このスライドのポイント
- よくある事故: 「画面側で検証済みだから」とサーバー側の検証を省く
- D-03のリクエストは、画面を経由せず直接送れる
- 道具を使えば、画面の検証を回避した不正なデータを送れる
- この事実が腹に落ちていないと、守りの薄いコードを危険と気づけない
信頼境界を「門」で捉える
信頼境界を、門の図で捉えましょう。門の外側は、何が届くか分からない世界です。門そのものが6点検査を行い、内側には検証済みのデータだけが入ります。ここで大切なのは、画面は門ではない、という点です。画面はあくまで利用者への親切であって、防御の門はサーバーの入口にしか置けません。門を通っていないデータを、内側でうっかり信用してしまうと、その一点から守り全体が崩れてしまいます。
このスライドのポイント
- 門の外側: 何が届くか分からない世界
- 門: 6点検査を行う場所
- 門の内側: 検証済みのデータだけが入る
- 画面は門ではない —— 防御の門はサーバーの入口にしか置けない
経費申請での6点検査
経費申請を例に、6点検査を具体的に見ます。金額が数値か、これは型の検査です。正の値か、これは範囲の検査です。申請者IDがその本人のものか、これは権限の検査。指定された部署IDが実在するか、これは存在確認です。この4つのうち、どれか一つが欠けるごとに、起こりうる事故の種類が一つずつ増えていきます。検証は、抜けの数だけ穴が空く守りだと考えてください。だからこそ、埋まっているかを一つずつ確かめる価値があります。
このスライドのポイント
- amountが数値か → 型
- 正の値か → 範囲
- 申請者IDが本人か → 権限
- 部署IDが実在するか → 存在確認
- 1点欠けるごとに、起こりうる事故の種類が1つ増える
技術サンプル: 検証で400を返す
07では、ハンドラーの入口で行う検証の擬似コードを見ます。種別はcode、目的は、不正な入力にD-06で学んだ400を返す形を確かめることです。読み方は二つあります。一つ、不正な入力には400、つまり依頼側の誤りを返します。二つ、検証はハンドラーの最初に置きます。AIへの質問例はこうです。「このハンドラーの入力検証を6点、型・形式・長さ・範囲・権限・存在で監査してください。欠けはどれですか」。なお、この書き方は枠組みによって変わります。
このスライドのポイント
- 種別: code ／ 目的: 不正な入力にD-06の400を返す形を確かめる
- サンプル本体（※枠組みにより書き方は変わる）:
クライアント側検証とサーバー側検証の総まとめ
ここで、クライアント側検証とサーバー側検証を総まとめします。H-05で学んだクライアント側検証は、画面上ですぐ間違いを知らせる「親切」でした。今回のサーバー側検証は、省略できない「防御」です。この二つは対立しません。利用者への親切のために画面でも検証し、防御のためにサーバーでも必ず検証する。二重に行うのが正しい姿です。画面で検証しているからサーバーを省く、という判断だけが誤りなのだと覚えてください。
このスライドのポイント
- H-05のクライアント側検証＝画面上ですぐ間違いを知らせる「親切」
- J-06のサーバー側検証＝省略できない「防御」
- 両者は対立しない。親切のために画面でも、防御のためにサーバーでも、二重に検証する
- 誤りは「画面で検証しているからサーバーを省く」という判断だけ
バイブコーディングでの確認点
確認を習慣にしましょう。AIが作った全てのハンドラーに、6点監査を定型の質問として依頼します。特に注意したいのは、権限と存在確認の2点です。この2点は、AIが省きがちだからです。型や範囲の検査は書けていても、その人がしてよい操作か、指定されたIDが本当に存在するか、という2点が抜けていることがあります。ここは必ず自分の目で確かめてください。質問例は「このハンドラーに権限と存在確認の検査はありますか」です。
このスライドのポイント
- AIが作った全ハンドラーに、6点監査を定型の質問として依頼する
- 特に「権限」と「存在確認」の2点はAIが省きがち
- 型や範囲は書けていても、この2点が抜けていないかを自分の目で確かめる
一問一答とまとめ
最後に一問一答です。検証済みのデータしか通さない線を、何と呼ぶでしょうか。……答えは、信頼境界です。30秒まとめです。サーバーの入口が信頼境界であり、そこで型・形式・長さ・範囲・権限・存在の6点を検査します。画面の検証は親切、サーバーの検証は防御で、省略できません。次回のJ-07では、検証を通った後の判断、業務ロジックへ進みます。関連資料は「AIアプリのセキュリティ超入門」「個人情報を扱うAIアプリ注意点」「テスト観点プロンプト50」です。
このスライドのポイント
- 一問一答: 検証済みのデータしか通さない線を何と呼ぶ？ → 信頼境界
- 30秒まとめ: サーバーの入口＝信頼境界。そこで型・形式・長さ・範囲・権限・存在の6点を検査。画面は親切、サーバーは防御で省略不可
- 次回J-07: 検証を通った後の判断＝業務ロジックへ
- 関連資料: 「AIアプリのセキュリティ超入門」「個人情報を扱うAIアプリ注意点」「テスト観点プロンプト50」
