初級では「外から来たものは信用しない」を土台としました。中級では、攻撃を境界で捉える視点で、コードを書くときの具体策を整理します（守り全体の層構成は姉妹ユニット Webのセキュリティ（全体像））。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
攻撃は「境界」で起きる
多くのWeb脆弱性は「信頼できない入力が、ある境界を越えて悪さをする」構図です。だから対策も境界ごとに決まります。
- ブラウザへ出す境界 → 出力エスケープ（XSS対策）
- DBへ渡す境界 → パラメータ化（SQLインジェクション対策）
- 他サイトからの操作の境界 → トークン／SameSite（CSRF対策）
- コードと秘密の境界 → シークレット管理（秘密情報の隔離）
登場人物メモ:
- ※1 信頼境界 — 信用できる領域と、できない領域の境目
- ※2 多層防御 — 対策を重ね、1つ破られても次で止める
アニメーション『信頼境界（外は信用しない）』を開く
この部分をもっと深く（上級）
「何を、誰から、どう守るか」を先に設計します。
- STRIDE — なりすまし・改ざん・否認・情報漏洩・DoS・権限昇格の観点で洗い出す
- 信頼境界の明示 — 図に境界を引き、越える所すべてで検証・認可
- 多層防御 — 予防・検知・対応を層で重ねる
やさしく言うと（初級）
すべての土台は「外から来たものは信用しない」。ブラウザから届く値も、URLのパラメータも、疑ってかかる。これを忘れると、次のような穴になります。
主な脅威と対策
- 入力検証 — 型・範囲・許可リストで、想定外を弾く（土台）
- XSS — 出力を文脈に応じてエスケープ、CSP でスクリプト実行を制限。なぜ効くか＝出力文脈（HTML属性・JS・URL）ごとに変換規則が違い、文脈に合った変換で初めて無害化されるため
- CSRF — CSRFトークン＋SameSite Cookie。SameSite は「クロスサイトからの Cookie 自動送信を抑制」することで、他サイト起点のなりすまし操作を成立させにくくする
- SQLインジェクション — プレースホルダ（パラメータ化クエリ）。なぜ効くか＝命令（SQL文）とデータ（入力値）を分離し、入力を文字列連結でSQLに混ぜないため
- 秘密管理 — 環境変数・シークレットマネージャ、鍵のローテーション
- その他 — アクセス制御（認可）、依存ライブラリの更新、監査ログ
この部分をもっと深く（上級）
- 入力 — 検証＋正規化（Unicodeの見た目差、二重デコード）
- 出力 — 文脈別エスケープ＋CSP／SRI
- 認証・認可 — 中央化、最小権限
- 暗号 — TLS＋保存時暗号、鍵管理
- 依存 — SCA／SBOMでサプライチェーンを管理
- 監視 — 監査ログ、異常検知、改ざん検知
やさしく言うと（初級）
- 入力の検証 — 外から来た値を、そのまま使わず確かめる（型・範囲・形式）
- XSS対策 — 出力を安全にして、他人のブラウザで悪いスクリプトを動かされないように
- CSRF対策 — ログイン中を悪用した「勝手な操作」を防ぐ
- SQLインジェクション対策 — 入力を通じてDBに不正な命令を送らせない
- 秘密情報の管理 — 鍵・パスワードをコードに直書きせず、隔離する
攻撃は、アプリと外の世界が触れ合う「境界」で起きます。だから守りも、境界ごとに置きます。
アニメーション『攻撃は境界で起きる』を開く
それぞれの詳しい手口と防ぎ方は、この下の各テーマで扱います。
運用まで含めて
- 既定は拒否 — 許可リスト方式（deny by default）
- 依存の管理 — 使っているライブラリの既知の脆弱性を放置しない
- 運用・監視 — 攻撃に気づける状態を保つ（運用の全体像は Webのセキュリティ（全体像））
- 代表的な指標 — OWASP Top 10 のような整理を出発点にする
この部分をもっと深く（上級）
- セキュリティヘッダ — CSP・HSTS・SRI・SameSite・X-Content-Type-Options
- サプライチェーン攻撃 — 依存やビルドパイプラインの汚染に注意
- シークレット — 集中管理＋ローテーション＋最小配布
- セキュアSDLC（シフトレフト） — 設計・CI・レビューにセキュリティを組み込む
やさしく言うと（初級）
- 多層で守る — 1つの対策に頼らず、入力検証・出力エスケープ・権限確認を重ねる
- サーバで最終確認 — フロントのチェックは親切機能。本当の守りはサーバ側
- 既定は安全側 — 迷ったら「拒否・非公開」から始める
⚠️ 破れ方のパターン
- 境界の取り違え — フロントで検証したから安全、と誤解（サーバで必ず再検証）
- 単一対策依存 — WAFだけ・エスケープだけに頼る
- 設定・依存の放置 — 公開設定ミス、古いライブラリの穴
この部分をもっと深く（上級）
- OWASP Top 10 — アクセス制御不備・インジェクション・設定ミスが上位常連
- 設定ミス — 公開設定・デフォルト資格情報・冗長な権限
- 依存の穴 — 既知脆弱性の放置
- CSPバイパス — 緩い設定や信頼した出所の悪用
- ログの不足／改ざん — 攻撃に気づけない・追えない
やさしく言うと（初級）
- 入力をそのまま画面に出す → XSS
- 入力をそのままDB命令に混ぜる → SQLインジェクション
- 鍵をリポジトリに置く → 秘密情報の漏洩
- 公開設定のミス → 見えてはいけないデータの露出
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 攻撃を「入力→処理→出力」のどこで防ぐか、の組み合わせで正しいのは？
問2. 「フロントで入力を検証したからサーバでは省略してよい」という考え方の評価として正しいのは？
問3. 多層防御（defense in depth）の考え方に最も近いのは？
問4. CSRF対策としてWebアプリで組み合わせる代表的な二つはどれか？
問5. XSS対策で、エスケープに加えてスクリプトの実行自体を制限する仕組みはどれか？
問6. SQLインジェクション対策のパラメータ化クエリが効く理由として正しいのは？
問7. 迷ったら「拒否・非公開」から始め、必要な通信だけ許可する既定方針を英語で何と呼ぶか。
問8. Webアプリの代表的なリスクを整理した、対策の出発点として使われる有名な一覧の名前は？