# OWASP A10:2025「例外的な状況の不適切な処理」とは？原因と対策

OWASP Top 10 2025で新設されたA10「Mishandling of Exceptional Conditions（例外的な状況の不適切な処理）」の意味、主なCWE、エラーメッセージからの情報漏れやフェイルオープンなどの攻撃例と、開発者がとるべき対策をOWASPの資料をもとに解説します。

OWASP Top 10の2025年版で、A10に新しく入ったのが「Mishandling of Exceptional Conditions（例外的な状況の不適切な処理）」です。エラー処理の不備、論理の誤り、異常時に「許可」側へ倒れてしまう実装（フェイルオープン）などをまとめたカテゴリで、2021年版のA10だったSSRFとは別物です。

<Points>

- 想定外の状況を「防げない・気づけない・正しく対応できない」ことが原因になる
- 典型例は、詳しすぎるエラーメッセージ、例外後に解放されない資源、途中で止まった取引
- 対策の軸は、エラーをその場で捕まえる・失敗したら「拒否」と全体のロールバックに倒す・処理を一か所にまとめる

</Points>

## A10:2025とは

OWASPは、このカテゴリを「プログラムが異常で予測できない状況を防ぎ、検知し、対応することに失敗したときに起こるもの」と説明しています。失敗は次の3段階に分けて考えられます。

<Flow
  title="例外的な状況への3つの段階"
  caption="どこか1つが欠けると、A10の脆弱性になる"
  steps={[
    { label: "防ぐ", note: "そもそも異常な状況を起こさせない" },
    { label: "検知する", note: "起きている異常に気づく" },
    { label: "対応する", note: "安全な状態に戻し、記録して知らせる" },
  ]}
/>

OWASPは原因として、入力値の検証の不足、エラーが起きた場所ではなく上位でまとめて処理していること、メモリ・権限・ネットワークなど環境の想定外の状態、例外処理の不統一、捕まえられないまま放置される例外を挙げています。そして「アプリケーションが次に何をすべきか分からなくなったときは、例外的な状況の処理を誤っている」としています。

<Stats source="OWASP Top 10:2025 A10 Mishandling of Exceptional Conditions">
<Stat value="24" label="このカテゴリに対応づけられたCWEの数" />
<Stat value="769,581" label="データ上の総出現数" />
<Stat value="3,416" label="関連するCVEの数" />
</Stats>

2021年版でA10だったSSRFは、2025年版ではA01「Broken Access Control」に統合されました。経緯は[SSRFの解説](/ssrf/)と[OWASP Top 10の解説](/owasp-top-10/)にまとめています。

## 主なCWE

OWASPがこのカテゴリの代表として挙げているCWEは次のとおりです。

<Figure title="A10:2025の主なCWE" source="OWASP Top 10:2025 A10">

| CWE | 内容 |
| --- | --- |
| CWE-209 | 機密情報を含むエラーメッセージの生成 |
| CWE-234 | 欠けたパラメータを処理できない |
| CWE-274 | 権限が足りない状況を正しく処理できない |
| CWE-476 | NULLポインタ参照 |
| CWE-636 | 安全に失敗しない（フェイルオープン） |

</Figure>

OWASPは、こうした不備から論理のバグ、オーバーフロー、競合状態（レースコンディション）、不正な取引、認証・認可の問題などが生まれ、機密性・可用性・完全性のすべてに影響しうるとしています。

## 攻撃のシナリオ

OWASPは具体例として3つのシナリオを示しています。

<Figure title="OWASPが示す攻撃シナリオ" source="OWASP Top 10:2025 A10">

| シナリオ | 何が起きるか |
| --- | --- |
| サービス妨害 | ファイルのアップロード中の例外は捕まえるが、資源を解放しない。例外のたびに資源がロックされ、最後には使える資源がなくなる |
| 機密情報の露出 | データベースのエラーがシステムの詳細ごと利用者に表示される。攻撃者はわざとエラーを起こして情報を集め、SQLインジェクションに役立てる |
| 取引の状態の破壊 | 引き落とし・入金・記録の複数段階の送金を、通信妨害で途中で止める。取引全体を巻き戻さないと、口座の残高を不正に抜かれたり、競合状態を突いて同じ送金先に何度も送られたりする |

</Figure>

2つ目のシナリオについて、OWASPは「利用者向けエラーメッセージの機密情報は偵察材料になる」と述べています。SQLインジェクションそのものの対策は[SQLインジェクションの解説](/sql-injection/)をご覧ください。

## 対策

OWASPの「How to Prevent」をもとに、実装・運用・設計の3つに分けて整理します。

<Steps>
<Step title="エラーはその場で捕まえ、回復をめざす">

例外が起きた場所で捕まえ、意味のある形で処理します。利用者には分かりやすいエラーを返し、出来事を記録し、必要なら通知を出します。それでも漏れたものは、アプリ全体のグローバル例外ハンドラーで受け止めます。

</Step>
<Step title="失敗したら「拒否」と全体のロールバックに倒す">

複数段階の取引が途中で失敗したら、部分的に直そうとせず、取引のすべての部分を巻き戻してやり直します（フェイルクローズ）。認可の確認で例外が出たときに、処理を続けてしまう実装は典型的なフェイルオープンです。

</Step>
<Step title="資源に上限を設ける">

レート制限、資源の割り当て（クォータ）、スロットリングなどで、例外的な状況そのものを起こしにくくします。OWASPは、上限のない資源はサービス妨害や総当たり攻撃を許すとしています。

</Step>
<Step title="入力を厳しく検証する">

想定外の値を早い段階で弾きます。受け入れざるを得ない危険な文字は、無害化やエスケープを行います。

</Step>
<Step title="処理を一か所にまとめ、監視する">

エラー処理・ログ・監視・通知・グローバル例外ハンドラーを一か所にまとめ、アプリ全体で同じ方法を使います。監視ツールで繰り返すエラーや攻撃のパターンを見つけ、防御や遮断につなげます。

</Step>
</Steps>

設計と検証の段階では、セキュリティ要件にこの方針を入れ、設計時の脅威モデリング、コードレビューと静的解析、完成したシステムへの負荷試験・性能試験・ペネトレーションテストを行うよう、OWASPは勧めています。

## エラーメッセージの出し方

OWASPのError Handling Cheat Sheetは、エラー応答からフレームワークやサーバーのバージョン、スタックトレースが漏れると、攻撃者の最初の偵察を助けると注意しています。利用者には汎用的なメッセージを返し、詳細はサーバー側のログに残すのが基本です。

<Compare>
<Column title="避けたい応答">

- スタックトレースをそのまま表示
- SQL文やファイルパスを含むエラー
- フレームワークのバージョンが分かる画面

</Column>
<Column title="望ましい応答" tone="accent">

- 「エラーが発生しました」などの汎用メッセージ
- 詳細はサーバー側のログに記録
- 原因に合ったHTTPステータスコード

</Column>
</Compare>

Expressを例にした、アプリ全体のエラーハンドラーの書き方です。

```js
// すべてのルートの後に置く、アプリ全体のエラーハンドラー
app.use((err, req, res, next) => {
  // 詳細はサーバー側のログにだけ残す
  logger.error({ err, path: req.path }, "unhandled error");

  // 利用者には実装の詳細を含まない応答を返す
  res.status(500).json({ message: "エラーが発生しました。時間をおいて再度お試しください。" });
});
```

チートシートは、クライアントが原因のエラーには4xx、サーバーが要求を処理できないときだけ5xxを使い、5xxの発生率を監視するよう勧めています。HTTP APIのエラー形式には、RFC 9457「Problem Details for HTTP APIs」という標準があります。

<Note tone="info">

同じエラーが大量に出るときは、一定の頻度を超えたら「何回・どの期間に起きたか」の統計にまとめて元のメッセージに付ける方法もOWASPは示しています。ログが埋もれず、自動の監視も働き続けます。

</Note>

## よくある質問

### Q. A10:2025はSSRFのことですか？

違います。SSRFは2021年版のA10でしたが、2025年版ではA01「Broken Access Control」に統合されました。2025年版のA10は「Mishandling of Exceptional Conditions」という新しいカテゴリです。

### Q. try-catchを書いておけば対策になりますか？

それだけでは足りません。例外を捕まえて何もしない、資源を解放しない、認可の確認を飛ばして処理を続けるといった書き方では、かえって脆弱性になります。捕まえた後に安全な状態へ戻し、記録して知らせるところまでが対策です。

### Q. 「フェイルオープン」とは何ですか？

異常が起きたときに、制限をかけずに処理を通してしまう状態です。CWE-636「Not Failing Securely」にあたります。認証や認可、入力の検証で例外が出たときは、通すのではなく拒否する側に倒すのが原則です。

出典: [OWASP Top 10:2025 A10 Mishandling of Exceptional Conditions](https://top10.owasp.org/2025/A10_2025-Mishandling_of_Exceptional_Conditions/)、[OWASP Top 10:2025 A01 Broken Access Control](https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/)、[OWASP Error Handling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html)、[RFC 9457「Problem Details for HTTP APIs」](https://www.rfc-editor.org/rfc/rfc9457)