初級・中級では「端末以外を守る囲い」と「攻撃の境界」を見ました。上級では、層で守るアーキテクチャと運用へ。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
守りを「層」で設計する
Webの守りは、リクエストが通る各層に配置します。手元（クライアント）は信用しない、が前提。
- エッジ — WAF、レート制限、ボット対策、DDoS緩和
- 通信 — TLS（HTTPS）、HSTSで常時暗号化を強制
- アプリ — 認証・認可、入力検証、出力エスケープ、CSP
- データ — 保存時暗号、最小権限、鍵管理
- 運用 — ログ・監視・シークレット管理・パッチ
各層の柱（詳細）
- エッジ／通信 — WAFルール、レート/ボット、TLS1.3、証明書自動更新
- セキュリティヘッダ — CSP・HSTS・COOP/COEP・Permissions-Policy・SameSite
- 認証・認可 — セッション/トークン、MFA、RBAC/ReBAC、最小権限
- アプリの守り — 入力(検証/正規化)・出力(文脈別エスケープ)・依存(SCA/SBOM)
- データ — 保存時暗号、機密の分離、バックアップ
- 可観測性 — 監査ログ、異常検知、改ざん検知
運用と文化
- ゼロトラスト — 内側も都度検証。境界防御の限界を補う
- サプライチェーン／CI — ビルド・依存・シークレットの汚染に備える（DevSecOps）
- 脅威モデリング — 設計段階でSTRIDE等で洗い出す
- 多層防御 — どこか1枚破られても、次の層で止める
⚠️ 破れ方
- 設定ミス — 公開設定・デフォルト資格・冗長な権限（最多の原因）
- ヘッダ不足 — CSP/HSTS未設定でXSSや盗聴の被害拡大
- 依存の脆弱性 — ライブラリの既知の穴を放置
- 境界の思い込み — 「内側だから安全」「TLSだから安全」（宛先やメタデータは見える）
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. Webのセキュリティを「層」で守るとき、各層の対応で正しいのは？
問2. 「内側のネットワークでも無条件に信用しない」Web運用の考え方は？
問3. 一度アクセスした以後は常時HTTPSを強制し、平文での接続をブラウザに禁じさせるヘッダはどれ？
問4. 「どこか1枚が破られても、次の層で止める」設計思想を指すのはどれ？
問5. 設計段階でSTRIDEなどを使い、起こりうる脅威を洗い出す活動はどれ？
問6. 本文が「最多の原因」として挙げる、Webセキュリティの破れ方はどれ？
問7. 「どの出所のスクリプトを実行してよいか」をブラウザに宣言し、XSSなどを緩和するセキュリティヘッダを英字3文字で答えてください。
問8. ソフトウェアに含まれる依存部品の一覧（部品表）を指す略語を英字4文字で答えてください。