【要約】備忘録：管理画面は /admin か admin.example.com か。「なんとなく」で選んでいたので、XSSの波及範囲から考え直しました [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
設計者が管理画面の配置を「なんとなく」で決めることで、XSSの被害が拡大する問題がある。
- ・
/adminは単なるパスであり、ブラウザ上の分離境界にならない。 - ・同一オリジンでは、公開ページのXSSから管理APIのレスポンスが読み取れる。
- ・サブドメイン分離のみでは、SameSite CookieによるCSRFを防げない。
- ・Cookieの書き込み権限により、Cookie tossing攻撃を受けるリスクがある。
// Approach
脆弱性の影響範囲を限定するため、ブラウザの境界とサーバーの認可を組み合わせた多層防御を採用する。
- ・管理画面を
admin.example.comへ分離し、オリジンを分ける。 - ・
__Host-プレフィックスを用い、Cookieの注入を防ぐ。 - ・BFFを導入し、管理画面とAPIの認証境界を一本化する。
- ・厳格なCSPを適用し、管理画面のセキュリティ強度を高める。
- ・サーバー側でテナントIDを用いた厳密な認可を実装する。
// Result
設計の区画化により、公開ページでXSSが発生しても管理システムへの波及を抑止できる。
- ・XSSによる管理APIのレスポンス読み取りを防止。
- ・Cookie tossingによるセッション侵害リスクを低減。
- ・管理画面専用の厳格なCSP運用が可能。
- ・「分離は認可の代替ではない」という設計指針を確立。
- ・多層防御による、堅牢なマルチテナント基盤の構築。
Senior Engineer Insight
> オリジン分離は脆弱性をゼロにするものではない。被害を区画化するための「投資」と捉えるべきだ。設計者は、ブラウザの境界（オリジン）とサーバーの境界（認可）を明確に区別せよ。BFFの導入や
__Host-プレフィックスの活用は、運用負荷を考慮しても、マルチテナント環境では必須の防衛策である。