【要約】X-Userヘッダを信じた予約APIで、誰でも他人になれた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が自宅ラボの予約システムを運用する中で、特定のAPIがユーザーのなりすましを許容している問題に直面した。設計上の「思い込み」が原因で、認証が不十分な状態となっていた。
- ・原因は、クライアントが送る
X-Userヘッダをサーバーが検証せずそのまま信頼していたこと。 - ・Cloudflare Accessによるヘッダ付与を前提としていたが、対象APIに設定が漏れていた。
- ・結果として、
curl等でヘッダを偽装するだけで、任意のメールアドレスとして予約操作が可能であった。
// Approach
開発者は、ユーザーの利便性（UX）を維持しつつ、最速で脆弱性を塞ぐための暫定的な対策を講じた。既存のGoogleログインの仕組みを活かし、サーバー側でトークンの正当性を確認する手法を採用した。
- ・案B（access_tokenのサーバー側検証）を採用。
- ・Googleの
tokeninfoエンドポイントへリクエストを送り、audやemail_verifiedを検証する。 - ・検証失敗時は「401 Unauthorized」を返すフェイルクローズ方式を徹底。
- ・外部通信のオーバーヘッドを抑えるため、検証結果を5分間キャッシュする。
// Result
対策の導入により、ヘッダ偽装によるなりすまし攻撃を完全に遮断することに成功した。受講者のログイン体験を損なうことなく、セキュリティレベルを大幅に向上させた。
- ・
X-Userヘッダを廃止し、Authorization: Bearerによる検証へ移行。 - ・なりすましを試みた3パターンの攻撃に対し、すべて401エラーで適切に拒絶した。
- ・将来的には、外部依存を減らし堅牢性を高めるため、ID Token（JWT）方式への移行を計画している。
Senior Engineer Insight
> 「設計の前提」と「実装の現実」の乖離は、大規模システムでも頻発する致命的なリスクだ。本件は、ミドルウェアの適用漏れというインフラ層のミスを、アプリケーション層の検証で補完した好例といえる。暫定策としての
access_token検証は、依存関係を増やさず迅速に問題を解決しており、現場判断として極めて合理的だ。ただし、Googleの可用性に依存する点は運用上の懸念となる。本質的な解決には、JWTを用いた自己完結型の検証への移行が不可欠である。