エラーハンドリング（セキュリティ観点）

エラーハンドリングは機能的な正確性だけでなく、セキュリティ上の情報漏洩を防ぐ観点からも設計が必要である。詳細なスタックトレース・データベーステーブル名・フレームワークのバージョン情報・ファイルシステムのパスなどが本番環境でクライアントに返されると、攻撃者が攻撃計画を立てるための貴重な情報となる。エラーレスポンスはユーザーに表示するメッセージと、サーバー側ログに記録する詳細情報を厳格に分離して設計することが基本となる。

RFC 9457（Problem Details for HTTP APIs）は、APIエラーレスポンスのJSON形式を標準化した仕様であり、type・title・status・detail・instanceのフィールドで構造化されたエラーを返す方法を定義している。この標準に従うことで、クライアントがエラーを一貫して処理できるようになり、内部実装の詳細を漏洩しない適切な抽象レベルのエラーメッセージを提供しやすくなる。

セキュリティ関連イベントのログ記録は、攻撃検出・事後調査・コンプライアンス対応のいずれにも不可欠である。ログイン失敗・権限エラー・レート制限超過・管理者操作などのイベントを記録する際は、ユーザーID・タイムスタンプ・IPアドレス・操作対象のリソースを含めることが監査証跡（Audit Trail）の要件となる。監査ログは別ストレージに書き込み、アプリケーションから直接変更・削除できない構造にすることで改ざん防止の信頼性を高められる。

コードレビューで着目するポイント

本番環境でスタックトレースや内部エラーメッセージがクライアントに返されていないか
エラーレスポンスにDBスキーマ・テーブル名・フレームワーク名・バージョンが含まれていないか
ユーザー存在確認に使えるエラーメッセージの違いがないか（メールアドレスの有効性等）
ログイン失敗・権限エラー・APIレート制限超過がセキュリティログに記録されているか
管理者操作（ユーザー削除・権限変更等）が監査ログとして記録されているか
エラーIDやトレースIDをクライアントに返し、詳細をサーバーログで追跡できる設計になっているか
ログに個人情報（パスワード・クレジットカード番号等）が含まれていないか

典型的なアンチパターン

本番環境でのスタックトレース返却: 500 Internal Server ErrorのレスポンスにJavaのスタックトレースやPythonのTraceback全体が含まれる実装。攻撃者はフレームワーク・バージョン・ファイル構造を把握でき、既知の脆弱性を探す手がかりになる。本番では汎用エラーメッセージのみを返し、詳細は構造化ログに記録する。

情報漏洩するエラーメッセージ: パスワードリセット機能で「このメールアドレスは登録されていません」と返す実装。攻撃者がユーザーリストを列挙するために使える。「登録済みの場合はリセットメールを送信しました」という統一メッセージにして、処理時間も均一にすること（タイミングサイドチャネル対策）。

セキュリティイベントのログ欠如: 認証失敗が1000回連続で発生してもログに何も記録されず、ブルートフォース攻撃が検知されない状態。SIEMやアラート設定の前提となるログ記録が不在では、攻撃が成功するまで気づかない。

参考リソース

RFC 9457: Problem Details for HTTP APIs — APIエラーレスポンスの標準形式仕様
OWASP Error Handling Cheat Sheet — セキュアなエラーハンドリングの実装ガイド
OWASP Logging Cheat Sheet — セキュリティログの記録内容・フォーマット・保護のガイド
OpenTelemetry (https://opentelemetry.io/) — 分散トレーシング・ログ・メトリクスの統合観測標準
NIST SP 800-92: Guide to Computer Security Log Management — ログ管理の政府標準ガイドライン