初級では「外から来たものは信用しない」を土台としました。中級では、攻撃を境界で捉える視点で、コードを書くときの具体策を整理します（守り全体の層構成は姉妹ユニット Webのセキュリティ（全体像））。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
攻撃は「境界」で起きる
多くのWeb脆弱性は「信頼できない入力が、ある境界を越えて悪さをする」構図です。だから対策も境界ごとに決まります。
- ブラウザへ出す境界 → 出力エスケープ（XSS対策）
- DBへ渡す境界 → パラメータ化（SQLインジェクション対策）
- 他サイトからの操作の境界 → トークン／SameSite（CSRF対策）
- コードと秘密の境界 → シークレット管理（秘密情報の隔離）
登場人物メモ:
- ※1 信頼境界 — 信用できる領域と、できない領域の境目
- ※2 多層防御 — 対策を重ね、1つ破られても次で止める
アニメーション『信頼境界（外は信用しない）』を開く
主な脅威と対策
- 入力検証 — 型・範囲・許可リストで、想定外を弾く（土台）
- XSS — 出力を文脈に応じてエスケープ、CSP でスクリプト実行を制限。なぜ効くか＝出力文脈（HTML属性・JS・URL）ごとに変換規則が違い、文脈に合った変換で初めて無害化されるため
- CSRF — CSRFトークン＋SameSite Cookie。SameSite は「クロスサイトからの Cookie 自動送信を抑制」することで、他サイト起点のなりすまし操作を成立させにくくする
- SQLインジェクション — プレースホルダ（パラメータ化クエリ）。なぜ効くか＝命令（SQL文）とデータ（入力値）を分離し、入力を文字列連結でSQLに混ぜないため
- 秘密管理 — 環境変数・シークレットマネージャ、鍵のローテーション
- その他 — アクセス制御（認可）、依存ライブラリの更新、監査ログ
運用まで含めて
- 既定は拒否 — 許可リスト方式（deny by default）
- 依存の管理 — 使っているライブラリの既知の脆弱性を放置しない
- 運用・監視 — 攻撃に気づける状態を保つ（運用の全体像は Webのセキュリティ（全体像））
- 代表的な指標 — OWASP Top 10 のような整理を出発点にする
⚠️ 破れ方のパターン
- 境界の取り違え — フロントで検証したから安全、と誤解（サーバで必ず再検証）
- 単一対策依存 — WAFだけ・エスケープだけに頼る
- 設定・依存の放置 — 公開設定ミス、古いライブラリの穴
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 攻撃を「入力→処理→出力」のどこで防ぐか、の組み合わせで正しいのは？
問2. 「フロントで入力を検証したからサーバでは省略してよい」という考え方の評価として正しいのは？
問3. 多層防御（defense in depth）の考え方に最も近いのは？
問4. CSRF対策としてWebアプリで組み合わせる代表的な二つはどれか？
問5. XSS対策で、エスケープに加えてスクリプトの実行自体を制限する仕組みはどれか？
問6. SQLインジェクション対策のパラメータ化クエリが効く理由として正しいのは？
問7. 迷ったら「拒否・非公開」から始め、必要な通信だけ許可する既定方針を英語で何と呼ぶか。
問8. Webアプリの代表的なリスクを整理した、対策の出発点として使われる有名な一覧の名前は？