コース目次 / 第4章
原則4 — 多層防御。1つのミスが、全滅にならない
CSPやCookie属性など「保険」として働く仕組みを、多層防御として整理します。3つの原則をレビュー用のチェックリストにまとめ、次のsec-auditへの橋を作ります。
ここまで3つの原則(データとコードの分離・許可リスト/既定拒否・状態と身元の保護)を見てきました。でも、人は間違えます。 どれだけ原則を知っていても、エスケープを一箇所忘れる、認可チェックを一つ書き漏らす——これは起き続けます。だから、最後にもう一つの発想が要ります。多層防御です。
1枚目が破れても、2枚目が止める
sec-csp で見た関係を思い出してください。本命は出力エスケープ(XSSを起こさせない)。でも、それが万一漏れても、CSP の script-src にインライン許可が無ければ、注入されたスクリプトは実行を拒まれます。
これが多層防御です——1つの守りが破れても、次の守りが被害を止める。「エスケープしているからCSPは要らない」でも「CSPがあるからエスケープは適当でいい」でもなく、両方を独立に効かせる。
ほかにも、あちこちにあった保険
HttpOnly Cookie(sec-auth)——XSS が起きても、セッションIDそのものは JavaScript から読めない。エスケープの保険。
SameSite Cookie(sec-auth)——CSRFトークンが未実装でも、他サイト起点のリクエストにはそもそも Cookie が付かない。CSRFトークンの保険。
実IPでの内部帯遮断(sec-serverside)——ホスト名の許可リストが DNS リバインディングで迂回されても、実際の接続先IPで最終防衛する。許可リストの保険。
再検証(旗艦・sec-report)——「直したつもり」を、同じ攻撃でもう一度確かめる。修正そのものの保険。
なぜ、これが要るのか
セキュリティは、「絶対に間違えない人」を前提にできません。大きなアプリになるほど、書く人も増え、見落としも増えます。多層防御は、「どこか1つが破られても、被害がそこで止まる」ように設計することで、人が間違えることそのものを前提に組み込みます。診断で「ここは守られているが、あそこは丸裸」という偏りを見つけたら、それも重大な指摘になります。
4つの原則 — レビューのチェックリストに
これで、体系化が完成しました。コードを読むときの、4つの問いです。
1. データとコードの分離 — この入力は、コードとして評価される経路に混ざっていないか。
2. 許可リストと既定拒否 — 危険を弾いているだけか、安全なものだけ許しているか。既定は拒否か。
3. 状態と身元の保護 — 事実はサーバが持っているか。操作に意図の確認はあるか。確認と実行に隙間はないか。
4. 多層防御 — 1つの守りが破れたとき、被害を止める2枚目はあるか。
持ち帰る一言
人は間違える。だから、1つの守りに頼らない。 本命の対策に加えて、破れたときに被害を止める保険を重ねる。これで4つの原則がそろいました——データとコード・許可リスト・状態と身元・多層防御。次はまとめて、この物差しを実際にコードへ当てる、次のコースへ橋を渡します。
こうなっていればOK
卒業まであと1章です。
この章はまだ完了していません。
保存できませんでした(プライベートブラウズ中かもしれません)。この端末に進捗は残りませんが、先へは進めます。