【要約】localhost なら本当に安全？ 外部サイトからローカル API を守るために実装した 4 つのこと [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がローカルAPIを構築する際、待ち受け先をlocalhostに限定しても防げない攻撃が存在する。ブラウザを介したリクエストは、ネットワーク層の制限を容易に回避するためである。
- ・外部サイトのJavaScriptによる、ローカルAPIへのリクエスト送信。
- ・CORSが制限するのはレスポンスの読み取りであり、リクエストの実行自体は防げない。
- ・DNSリバインディングによる、ドメイン名を介したローカルへの不正アクセス。
// Approach
開発者は、ブラウザの仕様とネットワーク攻撃の両面から、4つの多層防御策を講じた。これにより、リクエストの実行とレスポンスの読み取りの両方を制御する。
- ・SPAとAPIを同一オリジンに配置し、CORS設定を排除して外部からの読み取りを遮断。
- ・TrustedHostMiddlewareを用い、Hostヘッダーを検証してDNSリバインディングを防止。
- ・Sec-Fetch-Siteヘッダーを検証し、外部サイトからの状態変更リクエストを拒否。
- ・CSP等のセキュリティヘッダーを付与し、UIの読み込みや埋め込みを制限。
// Result
開発者は、多層的な防御策の実装とテストにより、ローカルAPIの安全性を担保した。これにより、外部サイトからの不正な操作を、API処理前に確実に遮断できる。
- ・外部サイトからの状態変更リクエストを、403 Forbiddenで拒否する仕組みを構築。
- ・DNSリバインディング攻撃に対し、Hostヘッダーの検証で防御を確立。
- ・テストコードにより、セキュリティ制約が実際の動作として守られていることを保証。
Senior Engineer Insight
> ローカルAPIをブラウザ経由で操作する構成では、ネットワーク層の制限だけでは不十分だ。本記事が示す「Sec-Fetch-Site」や「Hostヘッダー検証」による多層防御は、実戦的で非常に理にかなっている。特に、CORSの限界を正しく理解し、状態変更リクエストを明示的に拒否する設計は、堅牢なシステム構築において必須の視点である。テストによる自動検証まで組み込まれており、運用フェーズでのデグレード防止も考慮されている点が評価できる。