例外条件の扱い
OWASP Top 10:2025 の A10 を取得して読み、理解した内容を自分の言葉で書いたもの。
新設された理由
2025年版の新カテゴリ。24個の CWE を含む。
扱うのは、不適切なエラー処理、論理エラー、フェイルオープン、 その他の異常な状況に起因する問題。
新設の狙いは、「コード品質が低い」という漠然とした分類を、 具体的な指針を出せる形に置き換えること。
エラー処理がセキュリティの独立したカテゴリになった、という点自体が判断材料になる。
3つの失敗
脆弱になるのは、次の3段階のどこかで失敗しているとき。
1. 予防の失敗 異常な状況が起きるのを防げていない
2. 検知の失敗 起きている状況を認識できていない
3. 対応の失敗 起きた後の対応が不適切または不十分
根本原因として挙がっているもの。
入力検証が不十分
高いレイヤのエラー処理が、関数レベルの実装から切り離されている
環境側の予期しない問題(メモリ、権限、ネットワーク)
未処理の例外がシステムを予測不能な状態に置く
2番目が実務で見落としやすい。 「アプリ全体で例外を捕まえているから大丈夫」は、 発生箇所での意味のある回復を放棄しているという意味でもある。
フェイルオープンとフェイルクローズド
この章の中心。
エラー時は、部分的に回復しようとせず、トランザクションを全部ロールバックする(fail closed)。
原典の指摘が的確で、部分的な回復の試みこそが、 回復不能な誤りを生む場所になることが多い。
対する fail open は CWE-636 として、このカテゴリに明確に位置づけられている。
これは認証と認可の 「失敗時の例外処理を集約して、予測不能な状態に落ちるのを防ぐ」と同じ話。
対策
エラーは発生箇所で捕まえ、意味のある回復を行う
グローバルな例外ハンドラは、あくまで最後の安全網として置く
不完全なトランザクションは全部ロールバックする(fail closed)
レート制限、リソースの割り当て上限、スロットリングを入れる
エラー処理・ログ・監視をアプリケーション横断で中央化する
厳密な入力検証とサニタイズを行う
脅威モデリングとセキュリティのコードレビューを行う
グローバルハンドラは安全網であって、設計ではないという位置づけが明示されている。
レート制限とスロットリングがここに入っているのは、 分散システムの過負荷対策と同じ。 資源枯渇は異常条件の一種として扱われている。
攻撃シナリオ
資源枯渇 ファイルアップロードの例外が捕捉されず、資源が枯渇するまで掴まれ続ける
情報の露出 データベースのエラーがシステムの詳細を露出し、SQLインジェクションの偵察に使われる
取引の操作 取引の途中でネットワークが切れ、ロールバックが不十分だと口座を空にできる
3番目が fail closed の必要性を最も直接的に示している。
既存の記述との対応
このリポジトリには、A10 に該当する観点が既に散在していた。
| 既にある | ここでの位置づけ |
|---|---|
| バグ の「エラー時」「メモリ」「無限ループ」 | 予防の失敗の具体例 |
| トランザクション | ロールバックと分離レベル |
| 分散システム | リトライ可能なエラーと恒久的なエラーの区別 |
| API 設計 の「本番ではあえて曖昧に返す」 | 情報の露出への対処 |
| 認証と認可 | fail closed |
| 可観測性 | 検知の失敗への対処 |
散らばっていたものが1つのカテゴリとして名前を得た、というのがこの章の価値。
関連
- OWASP Top 10 — A10。2025年版で新設
- 設定の不備 — エラーメッセージの露出は両方にまたがる
- バグ — テストで検知しにくいもの
- 分散システム — 過負荷と資源枯渇
- Go — 戻り値でエラーを返す言語での具体。
errの握り潰しが見える形になる