【要約】認証漏れを直したら、姉妹サービスにも同じ穴が残っていた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、APIエンドポイントの追加時に認証の要否を都度判断していたため、セキュリティ上の脆弱性が蓄積した。
- ・AgentPickにて、記事取得やLLM分析をトリガーするAPIが未認証状態であった。
- ・IP制限のみでは、複数IPからの攻撃によるコスト増（LLM利用料等）を防げない。
- ・過去には、特定のパラメータにより全記事のキャッシュを削除できる破壊的な穴も存在した。
- ・これらは「認証の判断を仕組み化できていない」という共通の設計課題に起因する。
// Approach
開発者が、脆弱性の再発を防ぐため、認証の仕組みを共通化し、テストで保証する手法を採用した。
- ・既存のトークン認証を、対象となる2つのエンドポイントへ追加した。
- ・運用スクリプトには、環境変数から読み込む形式でトークンを渡すよう変更した。
- ・認証の成否を確認する回帰テストを実装し、修正の有効性を担保した。
- ・AgentPickでの修正方針を、同一構成を持つ姉妹サービスDevPickへ即座に横展開した。
// Result
開発者が、修正を単一のサービスに留めず、姉妹サービスへも適用することで、広範囲なリスクを排除した。
- ・AgentPickとDevPickの両方で、未認証APIおよび破壊的なパラメータを解消した。
- ・破壊的な操作を公開APIから撤去し、CLI実行のみに限定する運用へ移行した。
- ・認証の適用範囲が「入口」に限定されることを認識し、内部処理の安全性確認の重要性を得た。
- ・これにより、同様の構成を持つサービスにおける脆弱性の早期発見と修正が可能となった。
Senior Engineer Insight
> 認証は「入口」の防御に過ぎない。内部関数が直接呼ばれる定期実行などの経路を考慮した「処理自体の安全性」の設計が不可欠である。また、コード共有環境では1つの修正を全サービスへ横展開するプロセスを仕組み化すべきだ。単なる対症療法ではなく、設計判断の基準を標準化することが、大規模開発における再発防止の鍵となる。