OWASPトップテンに新たなリスクカテゴリー：予期せぬことを期待する
OWASPが2025年のトップ10を発表したことで、企業は特に注意すべき新しいリスク・カテゴリーをいくつか手に入れた。
新しいカテゴリーである「例外的な状況の誤った処理」は、組織が異常な状況や予測不可能な状況を防止、検出、対応する準備が整っていない場合に、何がうまくいかないかを概説している。OWASP によれば、この脆弱性は、アプリケーションが異常な事態の発生を防げなかったり、問題が顕在化したときにそれを特定できなかったり、予期せぬ事態が頭をもたげたときに対応が不十分であったり、まったく対応しなかったりする場合に引き起こされる可能性があります。
企業は、予期しなかった事態に備える必要があるという考え方は、今日の高度に分散し、相互接続されたシステムの現実を反映している。そして、OWASPが前例のない問題について話しているわけでもない。「例外的状況の誤った処理」には、24の共通弱点列挙（CWE）が含まれている。これらの CWE は、不適切なエラー処理、イベントのオープンの失敗、論理エラー、その他のシナリオを含み、異常な状 況下で発生する可能性があるというだけのことである。これは例えば、不適切な入力検証、処理関数における高レベルのエラー、例外の一貫性のない（あるいは存在しない）処理から生じる可能性があります。OWASP が述べているように、"アプリケーションが次の命令について確信が持てないときは、例外的な状 態が誤って処理されたときである"。
そのような例外的な状況は、システムを予測不可能な状態に陥らせ、システム・クラッシュや予期せぬ動作、長期にわたるセキュリティの脆弱性を引き起こす可能性がある。このような混乱を防ぐ鍵は、基本的に、最悪の事態を想定し、予期せぬことがいつ起きてもいいように計画することである。
例外的状況とトップテンの進化
ウェブアプリケーションセキュリティに対する最も深刻なリスクについて、4 年ごとに発表されるトップ 10 リストの構成は、4 年ごとに 1 つか 2 つが追加される程度で、いくつかのカテゴリがリストを移動する程度で、ここ数年はかなり安定しています。2025 年版では、第 10 位に「例外的な状況の誤処理」がランクインするなど、2 つの新しい項目が追加されました。もう1つは、3位にランクインした「ソフトウェア・サプライチェーンの失敗」で、これは以前のカテゴリーである「脆弱で時代遅れのコンポーネント」（2021年は6位）を拡張したもので、現在では幅広いソフトウェア侵害が含まれている。(スコアをつけるなら、「アクセス制御の失敗」が依然として1位を占めている）。
最新のカテゴリーを構成する例外的な条件は、ロジックのバグからオーバーフロー、不正なトランザクション、メモリ、タイミング、認証、認可などの問題に至るまで、多くの脆弱性を生み出す可能性がある。この種の脆弱性は、システムやそのデータの機密性、可用性、完全性に影響を与える可能性がある。OWASPによれば、これらの脆弱性は、攻撃者が脆弱性を悪用するために、例えばアプリケーションの欠陥のあるエラー処理を操作することを可能にする。
不測の事態に対処できない例として、サービス拒否攻撃でファイルがアップロードされている間に、アプリケーションが例外を識別し、その後リソースを解放しなかった場合があります。このような場合、リソースはロックされたまま、あるいは利用できないままとなり、リソースの枯渇を招きます。攻撃者が複数ステップの金融取引に侵入した場合、エラーが検出された時点で取引をロールバックしないシステムは、攻撃者がユーザーのアカウントを流出させる可能性がある。トランザクションの途中でエラーが検出された場合、「フェイルクローズド」、つまりトランザクショ ン全体をロールバックしてやり直すことが非常に重要である。トランザクションを途中でリカバリしようとすると、リカバリ不可能なミスが発生する可能性がある。
フェイルクローズドとフェイルオープンの比較
では、この2つの行動の違いは何か？明らかにしよう：
フェイルオープン：システムが "フェイルオープン "する場合、何か問題が発生しても動作し続けるか、"オープン "のままである。これは、物事を動かし続けることが非常に重要な場合に便利だが、セキュリティ上危険な場合もある。
フェイルクローズド：システムが「フェイルクローズド」であれば、問題が発生すると自動的にシャットダウンするか、安全な状態になる。不正アクセスを防ぐことができるため、セキュリティの観点からも安全である。
予期せぬエラーへの対応
この種のリスクを防ぐには、未知の事態を想定した計画を立てることから始まる。そして、起こりうるシステム・エラーが発生したときにそれを検知し、問題を解決するための手段を講じることができるようにすることです。攻撃者に重要な情報を漏らすことなく）ユーザーに適切に通知し、イベントを記録し、必要であれば警告を発することができなければなりません。
インジェクション・ポイントを特定するために使用できるSQLクエリー・エラーを、サイトのインストール・パスとともに開示した例を以下に示す：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:㊟appappindex_new.php on line 188
理想的なシステムは、見落とされたエラーをキャッチするためのグローバルな例外ハンドラーを備えていることである。また、モニタリングや観測可能なツールのような機能や、繰り返されるエラーや進行中の攻撃を示唆するパターンを検出する機能も備えていることが望ましい。これは、企業がエラーを処理する際の弱点を利用しようとする攻撃を防御するのに役立つ。
例えば、標準的なJavaウェブ・アプリケーションでは、グローバル・エラー・ハンドラをweb.xmlデプロイメント記述子レベルで設定することができます。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
この小さなコード・ブロックは、Javaウェブ・アプリケーションの裏側で何か問題が発生したときに何をすべきかを指示します。ユーザーに分かりにくいエラー・メッセージや真っ白な画面を見せる代わりに、問題を静かにキャッチし、カスタム・エラー・ページに送ります。この場合、そのページはerror.jspになります。
一般的なjava.lang.Exception型を扱うように設定されているため、アプリ全体のマスターエラーハンドラとして機能します。つまり、どこでエラーが発生しても、ユーザーは生の技術的な詳細を見るのではなく、同じフレンドリーで一貫性のあるエラーページにリダイレクトされます。
予期せぬ事態を防ぐ
理想を言えば、組織は、例外的な状況が発生しないように、可能な限り予防に努めるべきである。例えば、レート制限、リソースクォータ、スロットリング、その他の制限を実装することで、サービス拒否攻撃やブルートフォース攻撃から身を守ることができる。繰り返される同一のエラーを特定し、それらを統計としてのみ含めることで、自動化されたロギングやモニタリングの妨げにならないようにすることもできる。システムはまた、以下を含むべきである：
厳格な入力バリデーション。 適切に形成され、サニタイズされたデータのみがワークフローに入力されるようにする。これはデータフローの初期段階、理想的にはデータを受信した直後であるべきである。
エラーハンドリングのベストプラクティス。エラーは効率的に処理すべきである：ログを残し、必要に応じてアラートを送信しなければならないことをユーザーに明確に伝えましょう。グローバルエラーハンドラーは、見逃されたものをキャッチするのにも理想的です。
一般的なトランザクションの安全性も必須である。常に "フェイルクローズド "であること：何か問題が発生したら、トランザクション全体をロールバックすること。そして、トランザクションを中途半端に修正しようとしないこと。
ロギング、モニタリング、アラートの一元化に加え、グローバルな例外ハンドラにより、インシデントの迅速な調査やイベント処理の統一プロセスが可能になり、コンプライアンス要件への対応も容易になります。
プロジェクトの設計段階で行われる、脅威のモデリングおよび/または安全な設計レビュー。
コードレビューまたは静的解析、および最終システムで実施されるストレステスト、パフォーマンステスト、ペネトレーションテスト。
例外的状況への誤った対処」は新しいカテゴリーかもしれないが、サイバーセキュリティの基本原則に関わるものであり、企業が必ずしも予期していない事態に備える必要がある理由を強調するものである。例外的な状況がどのような形で発生するかは分からないかもしれないが、発生することは分かっている。重要なのは、すべての例外的な状況に同じように対処できるように準備しておくことであり、そうすることで、避けられない事態が発生したときに、その状況を検出し、対応することが容易になります。
SCW Trust Score™ ユーザーの皆様へ：
OWASP Top 10 2025の標準に合わせてLearning Platform コンテンツを更新しているため、フルスタック開発者のTrust Scoreが若干調整される可能性があります。ご質問やサポートが必要な場合は、カスタマー・サクセス担当者までご連絡ください。
.png)
OWASP Top 10 2025 の 10 位に「例外状態の誤処理」が追加された。フェイルクローズド」ロジック、グローバルエラーハンドラ、厳格な入力検証によってリスクを軽減する。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
OWASPが2025年のトップ10を発表したことで、企業は特に注意すべき新しいリスク・カテゴリーをいくつか手に入れた。
新しいカテゴリーである「例外的な状況の誤った処理」は、組織が異常な状況や予測不可能な状況を防止、検出、対応する準備が整っていない場合に、何がうまくいかないかを概説している。OWASP によれば、この脆弱性は、アプリケーションが異常な事態の発生を防げなかったり、問題が顕在化したときにそれを特定できなかったり、予期せぬ事態が頭をもたげたときに対応が不十分であったり、まったく対応しなかったりする場合に引き起こされる可能性があります。
企業は、予期しなかった事態に備える必要があるという考え方は、今日の高度に分散し、相互接続されたシステムの現実を反映している。そして、OWASPが前例のない問題について話しているわけでもない。「例外的状況の誤った処理」には、24の共通弱点列挙（CWE）が含まれている。これらの CWE は、不適切なエラー処理、イベントのオープンの失敗、論理エラー、その他のシナリオを含み、異常な状 況下で発生する可能性があるというだけのことである。これは例えば、不適切な入力検証、処理関数における高レベルのエラー、例外の一貫性のない（あるいは存在しない）処理から生じる可能性があります。OWASP が述べているように、"アプリケーションが次の命令について確信が持てないときは、例外的な状 態が誤って処理されたときである"。
そのような例外的な状況は、システムを予測不可能な状態に陥らせ、システム・クラッシュや予期せぬ動作、長期にわたるセキュリティの脆弱性を引き起こす可能性がある。このような混乱を防ぐ鍵は、基本的に、最悪の事態を想定し、予期せぬことがいつ起きてもいいように計画することである。
例外的状況とトップテンの進化
ウェブアプリケーションセキュリティに対する最も深刻なリスクについて、4 年ごとに発表されるトップ 10 リストの構成は、4 年ごとに 1 つか 2 つが追加される程度で、いくつかのカテゴリがリストを移動する程度で、ここ数年はかなり安定しています。2025 年版では、第 10 位に「例外的な状況の誤処理」がランクインするなど、2 つの新しい項目が追加されました。もう1つは、3位にランクインした「ソフトウェア・サプライチェーンの失敗」で、これは以前のカテゴリーである「脆弱で時代遅れのコンポーネント」（2021年は6位）を拡張したもので、現在では幅広いソフトウェア侵害が含まれている。(スコアをつけるなら、「アクセス制御の失敗」が依然として1位を占めている）。
最新のカテゴリーを構成する例外的な条件は、ロジックのバグからオーバーフロー、不正なトランザクション、メモリ、タイミング、認証、認可などの問題に至るまで、多くの脆弱性を生み出す可能性がある。この種の脆弱性は、システムやそのデータの機密性、可用性、完全性に影響を与える可能性がある。OWASPによれば、これらの脆弱性は、攻撃者が脆弱性を悪用するために、例えばアプリケーションの欠陥のあるエラー処理を操作することを可能にする。
不測の事態に対処できない例として、サービス拒否攻撃でファイルがアップロードされている間に、アプリケーションが例外を識別し、その後リソースを解放しなかった場合があります。このような場合、リソースはロックされたまま、あるいは利用できないままとなり、リソースの枯渇を招きます。攻撃者が複数ステップの金融取引に侵入した場合、エラーが検出された時点で取引をロールバックしないシステムは、攻撃者がユーザーのアカウントを流出させる可能性がある。トランザクションの途中でエラーが検出された場合、「フェイルクローズド」、つまりトランザクショ ン全体をロールバックしてやり直すことが非常に重要である。トランザクションを途中でリカバリしようとすると、リカバリ不可能なミスが発生する可能性がある。
フェイルクローズドとフェイルオープンの比較
では、この2つの行動の違いは何か？明らかにしよう：
フェイルオープン：システムが "フェイルオープン "する場合、何か問題が発生しても動作し続けるか、"オープン "のままである。これは、物事を動かし続けることが非常に重要な場合に便利だが、セキュリティ上危険な場合もある。
フェイルクローズド：システムが「フェイルクローズド」であれば、問題が発生すると自動的にシャットダウンするか、安全な状態になる。不正アクセスを防ぐことができるため、セキュリティの観点からも安全である。
予期せぬエラーへの対応
この種のリスクを防ぐには、未知の事態を想定した計画を立てることから始まる。そして、起こりうるシステム・エラーが発生したときにそれを検知し、問題を解決するための手段を講じることができるようにすることです。攻撃者に重要な情報を漏らすことなく）ユーザーに適切に通知し、イベントを記録し、必要であれば警告を発することができなければなりません。
インジェクション・ポイントを特定するために使用できるSQLクエリー・エラーを、サイトのインストール・パスとともに開示した例を以下に示す：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:㊟appappindex_new.php on line 188
理想的なシステムは、見落とされたエラーをキャッチするためのグローバルな例外ハンドラーを備えていることである。また、モニタリングや観測可能なツールのような機能や、繰り返されるエラーや進行中の攻撃を示唆するパターンを検出する機能も備えていることが望ましい。これは、企業がエラーを処理する際の弱点を利用しようとする攻撃を防御するのに役立つ。
例えば、標準的なJavaウェブ・アプリケーションでは、グローバル・エラー・ハンドラをweb.xmlデプロイメント記述子レベルで設定することができます。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
この小さなコード・ブロックは、Javaウェブ・アプリケーションの裏側で何か問題が発生したときに何をすべきかを指示します。ユーザーに分かりにくいエラー・メッセージや真っ白な画面を見せる代わりに、問題を静かにキャッチし、カスタム・エラー・ページに送ります。この場合、そのページはerror.jspになります。
一般的なjava.lang.Exception型を扱うように設定されているため、アプリ全体のマスターエラーハンドラとして機能します。つまり、どこでエラーが発生しても、ユーザーは生の技術的な詳細を見るのではなく、同じフレンドリーで一貫性のあるエラーページにリダイレクトされます。
予期せぬ事態を防ぐ
理想を言えば、組織は、例外的な状況が発生しないように、可能な限り予防に努めるべきである。例えば、レート制限、リソースクォータ、スロットリング、その他の制限を実装することで、サービス拒否攻撃やブルートフォース攻撃から身を守ることができる。繰り返される同一のエラーを特定し、それらを統計としてのみ含めることで、自動化されたロギングやモニタリングの妨げにならないようにすることもできる。システムはまた、以下を含むべきである：
厳格な入力バリデーション。 適切に形成され、サニタイズされたデータのみがワークフローに入力されるようにする。これはデータフローの初期段階、理想的にはデータを受信した直後であるべきである。
エラーハンドリングのベストプラクティス。エラーは効率的に処理すべきである：ログを残し、必要に応じてアラートを送信しなければならないことをユーザーに明確に伝えましょう。グローバルエラーハンドラーは、見逃されたものをキャッチするのにも理想的です。
一般的なトランザクションの安全性も必須である。常に "フェイルクローズド "であること：何か問題が発生したら、トランザクション全体をロールバックすること。そして、トランザクションを中途半端に修正しようとしないこと。
ロギング、モニタリング、アラートの一元化に加え、グローバルな例外ハンドラにより、インシデントの迅速な調査やイベント処理の統一プロセスが可能になり、コンプライアンス要件への対応も容易になります。
プロジェクトの設計段階で行われる、脅威のモデリングおよび/または安全な設計レビュー。
コードレビューまたは静的解析、および最終システムで実施されるストレステスト、パフォーマンステスト、ペネトレーションテスト。
例外的状況への誤った対処」は新しいカテゴリーかもしれないが、サイバーセキュリティの基本原則に関わるものであり、企業が必ずしも予期していない事態に備える必要がある理由を強調するものである。例外的な状況がどのような形で発生するかは分からないかもしれないが、発生することは分かっている。重要なのは、すべての例外的な状況に同じように対処できるように準備しておくことであり、そうすることで、避けられない事態が発生したときに、その状況を検出し、対応することが容易になります。
SCW Trust Score™ ユーザーの皆様へ：
OWASP Top 10 2025の標準に合わせてLearning Platform コンテンツを更新しているため、フルスタック開発者のTrust Scoreが若干調整される可能性があります。ご質問やサポートが必要な場合は、カスタマー・サクセス担当者までご連絡ください。
OWASPが2025年のトップ10を発表したことで、企業は特に注意すべき新しいリスク・カテゴリーをいくつか手に入れた。
新しいカテゴリーである「例外的な状況の誤った処理」は、組織が異常な状況や予測不可能な状況を防止、検出、対応する準備が整っていない場合に、何がうまくいかないかを概説している。OWASP によれば、この脆弱性は、アプリケーションが異常な事態の発生を防げなかったり、問題が顕在化したときにそれを特定できなかったり、予期せぬ事態が頭をもたげたときに対応が不十分であったり、まったく対応しなかったりする場合に引き起こされる可能性があります。
企業は、予期しなかった事態に備える必要があるという考え方は、今日の高度に分散し、相互接続されたシステムの現実を反映している。そして、OWASPが前例のない問題について話しているわけでもない。「例外的状況の誤った処理」には、24の共通弱点列挙（CWE）が含まれている。これらの CWE は、不適切なエラー処理、イベントのオープンの失敗、論理エラー、その他のシナリオを含み、異常な状 況下で発生する可能性があるというだけのことである。これは例えば、不適切な入力検証、処理関数における高レベルのエラー、例外の一貫性のない（あるいは存在しない）処理から生じる可能性があります。OWASP が述べているように、"アプリケーションが次の命令について確信が持てないときは、例外的な状 態が誤って処理されたときである"。
そのような例外的な状況は、システムを予測不可能な状態に陥らせ、システム・クラッシュや予期せぬ動作、長期にわたるセキュリティの脆弱性を引き起こす可能性がある。このような混乱を防ぐ鍵は、基本的に、最悪の事態を想定し、予期せぬことがいつ起きてもいいように計画することである。
例外的状況とトップテンの進化
ウェブアプリケーションセキュリティに対する最も深刻なリスクについて、4 年ごとに発表されるトップ 10 リストの構成は、4 年ごとに 1 つか 2 つが追加される程度で、いくつかのカテゴリがリストを移動する程度で、ここ数年はかなり安定しています。2025 年版では、第 10 位に「例外的な状況の誤処理」がランクインするなど、2 つの新しい項目が追加されました。もう1つは、3位にランクインした「ソフトウェア・サプライチェーンの失敗」で、これは以前のカテゴリーである「脆弱で時代遅れのコンポーネント」（2021年は6位）を拡張したもので、現在では幅広いソフトウェア侵害が含まれている。(スコアをつけるなら、「アクセス制御の失敗」が依然として1位を占めている）。
最新のカテゴリーを構成する例外的な条件は、ロジックのバグからオーバーフロー、不正なトランザクション、メモリ、タイミング、認証、認可などの問題に至るまで、多くの脆弱性を生み出す可能性がある。この種の脆弱性は、システムやそのデータの機密性、可用性、完全性に影響を与える可能性がある。OWASPによれば、これらの脆弱性は、攻撃者が脆弱性を悪用するために、例えばアプリケーションの欠陥のあるエラー処理を操作することを可能にする。
不測の事態に対処できない例として、サービス拒否攻撃でファイルがアップロードされている間に、アプリケーションが例外を識別し、その後リソースを解放しなかった場合があります。このような場合、リソースはロックされたまま、あるいは利用できないままとなり、リソースの枯渇を招きます。攻撃者が複数ステップの金融取引に侵入した場合、エラーが検出された時点で取引をロールバックしないシステムは、攻撃者がユーザーのアカウントを流出させる可能性がある。トランザクションの途中でエラーが検出された場合、「フェイルクローズド」、つまりトランザクショ ン全体をロールバックしてやり直すことが非常に重要である。トランザクションを途中でリカバリしようとすると、リカバリ不可能なミスが発生する可能性がある。
フェイルクローズドとフェイルオープンの比較
では、この2つの行動の違いは何か？明らかにしよう：
フェイルオープン：システムが "フェイルオープン "する場合、何か問題が発生しても動作し続けるか、"オープン "のままである。これは、物事を動かし続けることが非常に重要な場合に便利だが、セキュリティ上危険な場合もある。
フェイルクローズド：システムが「フェイルクローズド」であれば、問題が発生すると自動的にシャットダウンするか、安全な状態になる。不正アクセスを防ぐことができるため、セキュリティの観点からも安全である。
予期せぬエラーへの対応
この種のリスクを防ぐには、未知の事態を想定した計画を立てることから始まる。そして、起こりうるシステム・エラーが発生したときにそれを検知し、問題を解決するための手段を講じることができるようにすることです。攻撃者に重要な情報を漏らすことなく）ユーザーに適切に通知し、イベントを記録し、必要であれば警告を発することができなければなりません。
インジェクション・ポイントを特定するために使用できるSQLクエリー・エラーを、サイトのインストール・パスとともに開示した例を以下に示す：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:㊟appappindex_new.php on line 188
理想的なシステムは、見落とされたエラーをキャッチするためのグローバルな例外ハンドラーを備えていることである。また、モニタリングや観測可能なツールのような機能や、繰り返されるエラーや進行中の攻撃を示唆するパターンを検出する機能も備えていることが望ましい。これは、企業がエラーを処理する際の弱点を利用しようとする攻撃を防御するのに役立つ。
例えば、標準的なJavaウェブ・アプリケーションでは、グローバル・エラー・ハンドラをweb.xmlデプロイメント記述子レベルで設定することができます。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
この小さなコード・ブロックは、Javaウェブ・アプリケーションの裏側で何か問題が発生したときに何をすべきかを指示します。ユーザーに分かりにくいエラー・メッセージや真っ白な画面を見せる代わりに、問題を静かにキャッチし、カスタム・エラー・ページに送ります。この場合、そのページはerror.jspになります。
一般的なjava.lang.Exception型を扱うように設定されているため、アプリ全体のマスターエラーハンドラとして機能します。つまり、どこでエラーが発生しても、ユーザーは生の技術的な詳細を見るのではなく、同じフレンドリーで一貫性のあるエラーページにリダイレクトされます。
予期せぬ事態を防ぐ
理想を言えば、組織は、例外的な状況が発生しないように、可能な限り予防に努めるべきである。例えば、レート制限、リソースクォータ、スロットリング、その他の制限を実装することで、サービス拒否攻撃やブルートフォース攻撃から身を守ることができる。繰り返される同一のエラーを特定し、それらを統計としてのみ含めることで、自動化されたロギングやモニタリングの妨げにならないようにすることもできる。システムはまた、以下を含むべきである：
厳格な入力バリデーション。 適切に形成され、サニタイズされたデータのみがワークフローに入力されるようにする。これはデータフローの初期段階、理想的にはデータを受信した直後であるべきである。
エラーハンドリングのベストプラクティス。エラーは効率的に処理すべきである：ログを残し、必要に応じてアラートを送信しなければならないことをユーザーに明確に伝えましょう。グローバルエラーハンドラーは、見逃されたものをキャッチするのにも理想的です。
一般的なトランザクションの安全性も必須である。常に "フェイルクローズド "であること：何か問題が発生したら、トランザクション全体をロールバックすること。そして、トランザクションを中途半端に修正しようとしないこと。
ロギング、モニタリング、アラートの一元化に加え、グローバルな例外ハンドラにより、インシデントの迅速な調査やイベント処理の統一プロセスが可能になり、コンプライアンス要件への対応も容易になります。
プロジェクトの設計段階で行われる、脅威のモデリングおよび/または安全な設計レビュー。
コードレビューまたは静的解析、および最終システムで実施されるストレステスト、パフォーマンステスト、ペネトレーションテスト。
例外的状況への誤った対処」は新しいカテゴリーかもしれないが、サイバーセキュリティの基本原則に関わるものであり、企業が必ずしも予期していない事態に備える必要がある理由を強調するものである。例外的な状況がどのような形で発生するかは分からないかもしれないが、発生することは分かっている。重要なのは、すべての例外的な状況に同じように対処できるように準備しておくことであり、そうすることで、避けられない事態が発生したときに、その状況を検出し、対応することが容易になります。
SCW Trust Score™ ユーザーの皆様へ：
OWASP Top 10 2025の標準に合わせてLearning Platform コンテンツを更新しているため、フルスタック開発者のTrust Scoreが若干調整される可能性があります。ご質問やサポートが必要な場合は、カスタマー・サクセス担当者までご連絡ください。
OWASPが2025年のトップ10を発表したことで、企業は特に注意すべき新しいリスク・カテゴリーをいくつか手に入れた。
新しいカテゴリーである「例外的な状況の誤った処理」は、組織が異常な状況や予測不可能な状況を防止、検出、対応する準備が整っていない場合に、何がうまくいかないかを概説している。OWASP によれば、この脆弱性は、アプリケーションが異常な事態の発生を防げなかったり、問題が顕在化したときにそれを特定できなかったり、予期せぬ事態が頭をもたげたときに対応が不十分であったり、まったく対応しなかったりする場合に引き起こされる可能性があります。
企業は、予期しなかった事態に備える必要があるという考え方は、今日の高度に分散し、相互接続されたシステムの現実を反映している。そして、OWASPが前例のない問題について話しているわけでもない。「例外的状況の誤った処理」には、24の共通弱点列挙（CWE）が含まれている。これらの CWE は、不適切なエラー処理、イベントのオープンの失敗、論理エラー、その他のシナリオを含み、異常な状 況下で発生する可能性があるというだけのことである。これは例えば、不適切な入力検証、処理関数における高レベルのエラー、例外の一貫性のない（あるいは存在しない）処理から生じる可能性があります。OWASP が述べているように、"アプリケーションが次の命令について確信が持てないときは、例外的な状 態が誤って処理されたときである"。
そのような例外的な状況は、システムを予測不可能な状態に陥らせ、システム・クラッシュや予期せぬ動作、長期にわたるセキュリティの脆弱性を引き起こす可能性がある。このような混乱を防ぐ鍵は、基本的に、最悪の事態を想定し、予期せぬことがいつ起きてもいいように計画することである。
例外的状況とトップテンの進化
ウェブアプリケーションセキュリティに対する最も深刻なリスクについて、4 年ごとに発表されるトップ 10 リストの構成は、4 年ごとに 1 つか 2 つが追加される程度で、いくつかのカテゴリがリストを移動する程度で、ここ数年はかなり安定しています。2025 年版では、第 10 位に「例外的な状況の誤処理」がランクインするなど、2 つの新しい項目が追加されました。もう1つは、3位にランクインした「ソフトウェア・サプライチェーンの失敗」で、これは以前のカテゴリーである「脆弱で時代遅れのコンポーネント」（2021年は6位）を拡張したもので、現在では幅広いソフトウェア侵害が含まれている。(スコアをつけるなら、「アクセス制御の失敗」が依然として1位を占めている）。
最新のカテゴリーを構成する例外的な条件は、ロジックのバグからオーバーフロー、不正なトランザクション、メモリ、タイミング、認証、認可などの問題に至るまで、多くの脆弱性を生み出す可能性がある。この種の脆弱性は、システムやそのデータの機密性、可用性、完全性に影響を与える可能性がある。OWASPによれば、これらの脆弱性は、攻撃者が脆弱性を悪用するために、例えばアプリケーションの欠陥のあるエラー処理を操作することを可能にする。
不測の事態に対処できない例として、サービス拒否攻撃でファイルがアップロードされている間に、アプリケーションが例外を識別し、その後リソースを解放しなかった場合があります。このような場合、リソースはロックされたまま、あるいは利用できないままとなり、リソースの枯渇を招きます。攻撃者が複数ステップの金融取引に侵入した場合、エラーが検出された時点で取引をロールバックしないシステムは、攻撃者がユーザーのアカウントを流出させる可能性がある。トランザクションの途中でエラーが検出された場合、「フェイルクローズド」、つまりトランザクショ ン全体をロールバックしてやり直すことが非常に重要である。トランザクションを途中でリカバリしようとすると、リカバリ不可能なミスが発生する可能性がある。
フェイルクローズドとフェイルオープンの比較
では、この2つの行動の違いは何か？明らかにしよう：
フェイルオープン：システムが "フェイルオープン "する場合、何か問題が発生しても動作し続けるか、"オープン "のままである。これは、物事を動かし続けることが非常に重要な場合に便利だが、セキュリティ上危険な場合もある。
フェイルクローズド：システムが「フェイルクローズド」であれば、問題が発生すると自動的にシャットダウンするか、安全な状態になる。不正アクセスを防ぐことができるため、セキュリティの観点からも安全である。
予期せぬエラーへの対応
この種のリスクを防ぐには、未知の事態を想定した計画を立てることから始まる。そして、起こりうるシステム・エラーが発生したときにそれを検知し、問題を解決するための手段を講じることができるようにすることです。攻撃者に重要な情報を漏らすことなく）ユーザーに適切に通知し、イベントを記録し、必要であれば警告を発することができなければなりません。
インジェクション・ポイントを特定するために使用できるSQLクエリー・エラーを、サイトのインストール・パスとともに開示した例を以下に示す：
Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:㊟appappindex_new.php on line 188
理想的なシステムは、見落とされたエラーをキャッチするためのグローバルな例外ハンドラーを備えていることである。また、モニタリングや観測可能なツールのような機能や、繰り返されるエラーや進行中の攻撃を示唆するパターンを検出する機能も備えていることが望ましい。これは、企業がエラーを処理する際の弱点を利用しようとする攻撃を防御するのに役立つ。
例えば、標準的なJavaウェブ・アプリケーションでは、グローバル・エラー・ハンドラをweb.xmlデプロイメント記述子レベルで設定することができます。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
この小さなコード・ブロックは、Javaウェブ・アプリケーションの裏側で何か問題が発生したときに何をすべきかを指示します。ユーザーに分かりにくいエラー・メッセージや真っ白な画面を見せる代わりに、問題を静かにキャッチし、カスタム・エラー・ページに送ります。この場合、そのページはerror.jspになります。
一般的なjava.lang.Exception型を扱うように設定されているため、アプリ全体のマスターエラーハンドラとして機能します。つまり、どこでエラーが発生しても、ユーザーは生の技術的な詳細を見るのではなく、同じフレンドリーで一貫性のあるエラーページにリダイレクトされます。
予期せぬ事態を防ぐ
理想を言えば、組織は、例外的な状況が発生しないように、可能な限り予防に努めるべきである。例えば、レート制限、リソースクォータ、スロットリング、その他の制限を実装することで、サービス拒否攻撃やブルートフォース攻撃から身を守ることができる。繰り返される同一のエラーを特定し、それらを統計としてのみ含めることで、自動化されたロギングやモニタリングの妨げにならないようにすることもできる。システムはまた、以下を含むべきである：
厳格な入力バリデーション。 適切に形成され、サニタイズされたデータのみがワークフローに入力されるようにする。これはデータフローの初期段階、理想的にはデータを受信した直後であるべきである。
エラーハンドリングのベストプラクティス。エラーは効率的に処理すべきである：ログを残し、必要に応じてアラートを送信しなければならないことをユーザーに明確に伝えましょう。グローバルエラーハンドラーは、見逃されたものをキャッチするのにも理想的です。
一般的なトランザクションの安全性も必須である。常に "フェイルクローズド "であること：何か問題が発生したら、トランザクション全体をロールバックすること。そして、トランザクションを中途半端に修正しようとしないこと。
ロギング、モニタリング、アラートの一元化に加え、グローバルな例外ハンドラにより、インシデントの迅速な調査やイベント処理の統一プロセスが可能になり、コンプライアンス要件への対応も容易になります。
プロジェクトの設計段階で行われる、脅威のモデリングおよび/または安全な設計レビュー。
コードレビューまたは静的解析、および最終システムで実施されるストレステスト、パフォーマンステスト、ペネトレーションテスト。
例外的状況への誤った対処」は新しいカテゴリーかもしれないが、サイバーセキュリティの基本原則に関わるものであり、企業が必ずしも予期していない事態に備える必要がある理由を強調するものである。例外的な状況がどのような形で発生するかは分からないかもしれないが、発生することは分かっている。重要なのは、すべての例外的な状況に同じように対処できるように準備しておくことであり、そうすることで、避けられない事態が発生したときに、その状況を検出し、対応することが容易になります。
SCW Trust Score™ ユーザーの皆様へ：
OWASP Top 10 2025の標準に合わせてLearning Platform コンテンツを更新しているため、フルスタック開発者のTrust Scoreが若干調整される可能性があります。ご質問やサポートが必要な場合は、カスタマー・サクセス担当者までご連絡ください。
.png)
.png)
