はじめに

OWASP Top 10 2025は、2025年に公開された最新のセキュリティリスク指標です。
本記事では、OWASP Top 10の「2021→2025」で変わったポイントを整理しながら、各項目についてセキュリティ専業ベンダーの視点で丁寧に解説します。

まずOWASPとは、「Open Worldwide Application Security Project」の略で、アプリケーションのセキュリティ向上を目的とした国際的なオープンコミュニティです。

OWASP Top 10は、Webアプリケーションにおける重大なセキュリティリスクをまとめた代表的な指標として、世界中で広く参照されています。

OWASP Top 10 2025の概要を把握したい方や、2021年版からの変更点を押さえたい方は、ぜひ最後までご覧ください。

※OWASP Top 10 2025は、公式サイトにて公開されていますが、公開プロセスの特性上、今後内容が調整される可能性もあります。本記事では、現時点の公開情報をもとに2021年版との違いを整理します。

INDEX

はじめに

OWASP Top 10 2025と2021の違い

「OWASP Top 10 2025」のA01～A10 各項目を読み解く
┗ A01: Broken Access Control（アクセス制御の不備）
┗ A02: Security Misconfiguration（セキュリティ設定ミス）
┗ A03: Software Supply Chain Failures（ソフトウェア・サプライチェーンの不具合）
┗ A04: Cryptographic Failures（暗号化の失敗）
┗ A05: Injection（インジェクション）
┗ A06: Insecure Design（安全でない設計）
┗ A07: Authentication Failures（認証の失敗）
┗ A08: Software or Data Integrity Failures（ソフトウェア/データ整合性の不具合）
┗ A09: Security Logging and Alerting Failures（ログ＆アラートの不備）
┗ A10: Mishandling of Exceptional Conditions（例外条件の誤った処理）

まとめ：OWASP Top 10 2025では「セキュリティ設定ミス」が大きく順位を上げた！
┗参考サイト

採用情報

OWASP Top 10 2025と2021の違い

2025順位	2025カテゴリ名	2021での位置づけ	2021→2025の変更点
1	A01: Broken Access Control（アクセス制御の不備）	2021→1位	統合あり：2021の#A10（SSRF）などを含む形でアクセス制御の観点が強化
2	A02: Security　Misconfiguration（セキュリティ設定ミス）	2021→5位	順位上昇：設定不備に起因するリスクの重要性が高まり、順位が上昇
3	A03: Software Supply Chain Failures（ソフトウェア・サプライチェーンの不具合）	2021→6位 #A06: Vulnerable and Outdated Components（脆弱で古いコンポーネント）	新設：2021のA06（脆弱で古いコンポーネント）に関連する領域を拡張し、サプライチェーン全体のリスクとして再整理
4	A04: Cryptographic Failures（暗号化の失敗）	2021→2位	順位低下：#A02→A04
5	A05: Injection（インジェクション）	2021→3位	順位低下：#A03→A05
6	A06: Insecure Design（安全でない設計）	2021→4位	順位低下：#A04→A06 他カテゴリの順位が上がった影響として説明
7	A07: Authentication Failures（認証の失敗）	2021→7位 #A7：識別と認証の不備（Identification and Authentication Failures）	名称変更：順位はそのままに、より実態に合うよう名称を簡略化
8	A08: Software or Data Integrity Failures（ソフトウェア/データ整合性の不具合）	2021→8位 #A8：Software and Data Integrity Failures	文言変更：and→or 順位は8位のまま維持
9	A09: Security Logging and Alerting Failures（ログ＆アラートの不備）	2021→9位 #A9：Security Logging and Monitoring Failures	名称変更：Monitoring　→Alerting 検知・対応の観点がより重視された構成
10	A10: Mishandling of Exceptional Conditions（例外条件の誤った処理）	2021では該当カテゴリなし	新設：例外処理やエラーハンドリングの不備に起因するリスクを独立したカテゴリとして整理

※本表は2021年版との対応関係をもとにした参考比較です。カテゴリの統合・再編を含むため、単純な順位変動を示したものではありません。

「OWASP Top 10 2025」のA01～A10 各項目を読み解く

「OWASP Top 10」は、Webアプリの主要なリスクを押さえるためのドキュメントで、設計・実装・運用におけるセキュリティ対策の抜け漏れ確認に役立ちます。

以下では、A01～A10の各項目について、内容と現場で起きやすい典型例、対策のポイントを説明します。

A01: Broken Access Control（アクセス制御の不備）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	40
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	20.15%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	3.74%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	100.00%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	42.93%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.04
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	3.84
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	1,839,701
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	32,654

アクセス制御の不備は、認可システムの欠陥によって本来許可されていない操作や情報取得が可能になるリスクです。
この制御を簡単に説明すると、「対象のユーザが、どの情報や機能にアクセスしていいか」を正しく判断して止める仕組みです。
アクセス制御が不適切であると、本来見えてはいけないはずの情報が見えたり、できないはずの操作ができたりします。

アクセス制御の不備の典型例と対策

代表的な例としては、「IDOR（Insecure Direct Object Reference）」が挙げられます。
これは、URLやパラメータ内のIDを書き換えるだけで、他人のデータにアクセスできてしまう脆弱性です。
例えば、URLやパラメータに入っている「ユーザID」「注文ID」などの番号を変えるだけで、他人のデータが見えてしまう状態を指します。

対策は、URLやパラメータで指定された対象（IDなど）について、サーバ側で必ず、該当ユーザがデータにアクセスできるかを検証することです。

実装としては、取得クエリに所有者やテナント条件を含める、もしくは認可ミドルウェア・共通関数でチェックを中央化するのが効果的です。

A02: Security Misconfiguration（セキュリティ設定ミス）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	16
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	27.70%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	3.00%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	100.00%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	52.35%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.96
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	3.97
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	719,084
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	1,375

セキュリティ設定ミスは、コード自体に重大な欠陥がなくても、環境や構成の不備によって発生する重大なリスクです。

サーバ・クラウド・コンテナ・フレームワーク・HTTPヘッダなどの設定が適切に管理されていないと、攻撃者にとって侵入しやすい環境になります。

本来は外部に見えない管理画面が公開されてしまったり、内部向けの情報（設定ファイルやログ）が誰でも見られるようになっていたりして、攻撃や情報漏えいに直結します。

セキュリティ設定ミスの典型例と対策

一例として、クラウドストレージが誤って公開設定のまま運用され、誰でもファイルを閲覧できるまま放置されている事案です。対策としては、設定が安全な形で固定される仕組みに寄せるのが有効です。

まず、公開範囲や権限は、「最初から制限する（Secure by Default）」を基本にし、例外を作るときは理由と期限を明確にします。
また、「IaC（Infrastructure as Code）」で構成をコード管理し、レビューや差分管理を可能にしてください。

このように自動構成チェックや継続的な監査を組み合わせると、ヒューマンエラーを大幅に減らせます。

A03: Software Supply Chain Failures（ソフトウェア・サプライチェーンの不具合）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	6
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	9.56%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	5.72%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	65.42%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	27.47%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	8.17
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	5.23
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	215,248
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	11

ソフトウェア・サプライチェーンの不具合は、外部部品やビルド・配布工程が侵害され、不正コードが正規のプロセスを通じて実行されてしまうリスクです。

ソフトウェア・サプライチェーンには、以下の工程が含まれます。

• 外部部品（OSSライブラリなど）
• ビルド基盤（CI/CD）
• 配布する成果物（コンテナイメージやビルド済みファイル）

サプライチェーンの不具合のリスクでは、開発者の気づかないうちに悪意ある部品が混ざったり、正規のリリース物がすり替わったりして、ユーザに被害が広がります。

ソフトウェア・サプライチェーンの不具合の典型例と対策

例えば、名前がよく似た偽のパッケージ（タイポスクワッティング）や、ライブラリが改ざんされたものに置き換わると、ビルドの時点で不正コードが混入します。

結果として、本番にデプロイされたアプリが「最初から不正動作する」かたちになり、情報送信や不正操作の踏み台にされる事例があります。

対策は、怪しいものが入りにくい仕組みを作ることです。 「依存関係の固定化（ロックファイル）」やSBOMによる可視化に加え、成果物の署名・検証、CI/CDのアクセス制御強化など、信頼性を高める仕組みの構築が重要です。

A04: Cryptographic Failures（暗号化の失敗）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	32
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	13.77%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	3.80%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	100.00%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	47.74%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.23
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	3.90
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	1,665,348
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	2,185

暗号化の失敗は、機密データを適切に保護できていない状態を指します。
暗号化を実装しているときでも、不適切なアルゴリズムを使用していたり、鍵管理が不適切だったりすると、実質的に保護されていないのと同じです。

鍵管理や暗号化に不備があると、通信の盗み見や、保存データの流出時に中身まで丸見えになるなど、被害が直接的になりやすいのが特徴です。

暗号化の失敗の典型例と対策

例えば、古いTLSバージョンの利用、脆弱なハッシュ関数（MD5やSHA-1）の使用、パスワードの不適切な保存、証明書検証の無効化などが典型例です。

また、暗号鍵をコードや設定ファイルに書いていたり、複数環境（開発・検証・本番）で使い回していたりすると、攻撃者に盗まれやすくなります。

対策は、強固な暗号方式の採用だけでなく、鍵管理を安全に行う仕組みづくりが不可欠です。

通信は原則「HTTPS（TLS）」で統一し、証明書検証を徹底します。
さらに、鍵の分離管理や定期ローテーション、クラウドのKMSやSecrets Managerの活用により、万が一の影響範囲を最小化できます。
加えて、ログやエラーメッセージにトークンやパスワードなどの機密情報を出力しない設計を徹底し、暗号以前の情報漏えいを防ぐことも重要です。

A05: Injection（インジェクション）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	37
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	13.77%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	3.08%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	100.00%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	42.93%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.15
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	4.32
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	1,404,249
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	62,445

インジェクションは、アプリが受け取った入力によって、想定していない命令やクエリが実行されてしまうリスクです。

攻撃者は、検索フォームやURLパラメータなどに細工した値を送り込み、データベースクエリ・OSコマンド・テンプレートエンジンなどの処理を意図通りに操作しようとします。
インジェクション攻撃を受けると、本来見えないデータを読み取られたり、データを書き換えられたり、場合によってはサーバ上で不正な操作をされることがあります。

インジェクションの典型例と対策

代表例はSQLインジェクションで、入力値に不正なSQL断片を混入されると、認証回避やデータの取得・改ざんが可能になります。

対策は、悪意のある入力を命令として解釈しない仕組みを設けるのが効果的です。

まず基本は、データベース操作なら「プレースホルダ（パラメータ化クエリ）」を徹底し、文字列連結でSQLを組み立てないようにします。

さらに、HTML表示やテンプレート処理では、表示先の文脈に合ったエスケープ（特殊文字の無害化）を適用しましょう。 入力チェックはフロントだけで安心せず、必ずサーバ側でも同じルールで検証し、重要なAPIや管理機能から優先的に点検していくと現場でも効果的です。

A06: Insecure Design（安全でない設計）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	39
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	22.18%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	1.86%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	88.76%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	35.18%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	6.96
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	4.05
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	729,882
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	7,647

安全でない設計は、仕様・設計の段階で必要なセキュリティ要件や制御が定義されず、アーキテクチャや仕様に組み込まれていない状態を指します。

実装が仕様通りでも、悪用シナリオに対するガードレール（権限境界・状態遷移の検証・レート制限・再認証・監査など）が弱いと、攻撃や不正利用が成立します。

安全でない設計は「誰が・何を・どこまでできるか」「悪用されたらどうなるか」といった前提を十分に決めないまま機能を作ると起こりやすいです。

安全でない設計の典型例と対策

典型例として挙げられるのは、「必要以上の情報を返す」設計です。

ユーザの一覧画面を作るときに、不要な「住所・電話番号・生年月日」などの個人情報までAPIがまとめて返す設計にしてしまう事例があります。
これは設計の時点で「機能に必要なデータは？」「返してよい範囲は？」といった、セキュリティ要件が定義されていないのが原因です。

対策は、開発の早い段階で安全要件を決め、仕様・設計に組み込むことです。
まず「必要なデータだけを返す」を原則にし、データを必要最小限に絞ります。

次に、もし悪用されたら何が起きるかを考え、機能の性質に合わせた守りを仕様として入れます。
設計レビューを習慣化し、「誰が使う？・何が見える？・困るのは何？」の3点をチェックするだけでも、設計由来の事故の削減が可能です。

A07: Authentication Failures（認証の失敗）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	36
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	15.80%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	2.92%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	100.00%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	37.14%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.69
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	4.44
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	1,120,673
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	7,147

認証の失敗は、ログインや本人確認、認証状態の維持（セッション/トークン管理）が甘く、攻撃者が他人になりすまして利用できてしまうリスクです。

認証は、利用者が誰かを確かめる仕組みで、ID/パスワード、ワンタイムコード（SMS・認証アプリ）、SSOなどが含まれます。
認証が突破されると、攻撃者は正規ユーザとしてOSやアプリ、クラウドサービスを操作でき、閲覧可能な情報や実行できる機能が悪用されます。
特に管理者など高権限アカウントが侵害されると被害が急拡大しやすいです。

認証の失敗の典型例と対策

例の一つには、「パスワード総当たり（ブルートフォース）」や「パスワードリスト攻撃」に対する防御不足があります。

ログイン失敗が続いても試行回数の上限や一時ロックなどがないと、攻撃者は大量のパスワード候補を機械的に試して突破してきます。
また、パスワードリセット機能が「何度でもできる」「トークンやリンクが長時間有効」などになっていると危険です。

対策は「強いパスワード」だけを過信せず、MFAで突破されにくくし、突破されても被害を広げにくい構造（最小限の権限）にすることです。

1. ログインには「回数制限・段階的な遅延・怪しい試行の検知」を入れる
2. MFA（多要素認証）を導入し、管理者・重要操作には必須化する
3. パスワードリセットには「本人通知・短い有効期限・回数制限」を設定

上記の3点を押さえるだけで、認証まわりの事故を大きく減らせます。

A08: Software or Data Integrity Failures（ソフトウェア/データ整合性の不具合）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	14
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	8.98%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	2.75%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	78.52%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	45.49%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.11
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	4.79
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	501,327
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	3,331

ソフトウェア/データ整合性の不具合は、「正しいものを使っているつもりなのに、改ざんに気づけない」タイプのリスクです。

ここでいう整合性（完全性）とは、改ざんされていないかを検証できる仕組み、そして正規の配布物・正当な送信元だと確認できるものを指します。

整合性チェックがないと、偽のデータや改ざんされた成果物を扱ってしまい、不正処理や情報漏えい、不正コードの混入につながります。

ソフトウェア/データ整合性の不具合の典型例と対策

典型例として、外部から取り込むデータ（Webhookや連携APIの通知など）を本物と確認せずに処理してしまうケースがあります。

形式が正しければ通ってしまう設計だと、送信元のなりすましや改ざん、リプレイ（過去データの再送）を防げません。

対策は「検証・確認できないものを通さない仕組みにする」です。

• 外部データは署名検証（HMAC等）を必須化
• タイムスタンプやnonceでリプレイ対策を入れて処理
• 更新ファイルや成果物は、ハッシュや署名で検証して利用
• 可能なら署名付きファイルの検証を自動化

まずは影響の大きい入口（外部データ・更新/配布物）から優先的に、整合性チェックを組み込むのが現実的です。

A09: Security Logging and Alerting Failures（ログ＆アラートの不備）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	5
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	11.33%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	3.91%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	85.96%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	46.48%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.19
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	2.65
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	260,288
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	723

ログ＆アラートの不備は、攻撃や不正が起きても検知できない、また発覚後に原因や影響範囲を追えないタイプのリスクです。

ログは、システム上の出来事（ログイン成功/失敗・権限変更、データ参照・設定変更など）の記録で、アラートは異常な兆候を検知して初動につなげる通知の仕組みです。

ログ＆アラートの整備が不十分であると侵入が長期間見逃され、被害範囲の特定や復旧、説明対応のコストが一気に跳ね上がります。

ログ＆アラートの不備の典型例と対策

典型的なのは、重要イベントがログに残っていない、または残っていても相関が使える形になっていない状態です。

例えば、管理者操作や権限変更が記録されない、記録しても「誰が・いつ・何をしたか」が追えない、時刻がズレていて時系列が再現できない、といった場合です。

対策は、ログを大量に集めるよりも、重要な出来事を確実に残し、運用できるように整えることです。
まず最低限のログを定義し、アプリ・クラウド・ID基盤などに散らばるログを集約して検索・相関できるようにします。
加えて、ログの保全（改ざんや削除されにくい保存、適切な保持期間）、時刻同期も押さえると調査の精度が上がります。

アラートは最初から完璧を狙わず、「短時間のログイン失敗多発」「深夜の管理操作」「急な大量データ出力」など優先度の高い通知から始めると運用が回ります。
そして、通知が来たときの担当・連絡先・一次対応手順・判断基準を必ず決めておきましょう。

A10: Mishandling of Exceptional Conditions（例外条件の誤った処理）

CWEs Mapped(※1)	カテゴリに含まれるCWEの種類数 ※1 Common Weakness Enumeration：弱点分類	24
Max Incidence Rate	カテゴリ内で最も発生率が高いCWEの発生率	20.67%
Avg Incidence Rate	カテゴリに含まれるCWE全体の平均発生率	2.95%
Max Coverage	カテゴリ内で最も広くテスト対象になっていたCWEのテスト範囲	100.00%
Avg Coverage	カテゴリに含まれるCWE全体で見た、平均的なテスト範囲	37.95%
Avg Weighted Exploit	悪用しやすさを10点尺度で平均した指標	7.11
Avg Weighted Impact	技術的な影響の大きさを示す平均指標	3.81
Total Occurrences	カテゴリのCWEが見つかったアプリの総数	769,581
Total CVEs(※2)	CWEに関連する、NVD上の既知脆弱性の件数 ※2 Common Vulnerabilities and Exposures：個別脆弱性ID	3,416

例外条件の誤った処理は、平常時に問題なく動く一方で、想定外の事象が発生した瞬間にセキュリティ前提が崩れるタイプの脆弱性です。

ここでいう例外条件とは、「エラー・タイムアウト・通信断・想定外の入力・外部サービスの障害・リソース枯渇・ロールバック漏れ」などを指します。
例外条件への備えが不十分だと、攻撃や事故の引き金になり、結果として認証・認可のすり抜けや権限昇格につながる事例があります。

例外条件の誤った処理の典型例と対策

典型例は、エラー時に処理が停止せず、本来止めるべき処理が通ってしまう（fail-open）です。

例えば、外部認証がタイムアウトした際に「エラーでも許可する」実装だと危険です。
攻撃者は大量リクエスト等でタイムアウトを誘発し、権限チェックを回避する可能性があります。

以下もよくあるリスクです。

• エラー画面に内部情報（設定値・パス・SQL断片・スタックトレース等）が表示され、攻撃のヒントになる
• 例外時にロールバックや後片付けが漏れる（処理途中で止まる/二重処理が起きる）
• 例外や再試行が連鎖してリソース枯渇を起こし、DoSにつながる（接続リーク等）

対策は、例外が起きてもリスクにならないように「安全に処理する（fail securely）」設計にすることです。

まず、認可・決済・権限変更など重要処理に関わる部分は、外部連携が失敗したときに「通さない（fail closed）」を基本にします。
次に、タイムアウトやリトライ処理では、冪等性（同じ要求を繰り返しても結果が変わらない）を担保してください。
最後に、内部ログには原因追跡に必要な情報を残して、A09（ログ＆アラート）と連動した運用まで整えると、例外条件が事故に発展しにくくなります。

まとめ：OWASP Top 10 2025では「セキュリティ設定ミス」が大きく順位を上げた！

2025版OWASP Top 10では「A02: Security Misconfiguration（セキュリティ設定ミス）」が5位から2位に大きく上昇しました。

クラウド・コンテナ・フレームワークなど、設定で挙動が決まる領域が増えたため、ミスがそのまま侵入口になりやすい実態が背景にあります。

OWASPでも「設定不備はより一般的になっている」とされ、リスクの重大さが強調されています。

だからこそ、いま求められているのは「アプリ×インフラ×運用」を横断して、設定起因によるリスクを減らせる人材です。

2025 OWASPをきっかけに、セキュリティへの意識と対策をより高めていきましょう！

参考サイト

https://owasp.org/Top10/2025

https://owasp.org/Top10/2021/ja

採用情報

セキュアイノベーションでは以下のページで採用情報を公開しています。
OWASPの知識が役立つ業種にて採用募集中！　未経験歓迎！

https://www.secure-iv.co.jp/recruit

セキュアイノベーション採用情報（新卒・転職・未経験）
公式サイトからの応募・採用で入社祝い金30万円支給
※2025年8月1日以降の応募のみ対象　
※公式サイトから直接応募者に限る