Webアプリケーションのセキュリティを語るうえで、最も広く参照されている基準が「OWASP Top 10」です。そのOWASP Top 10が、2021年版から約4年ぶりに更新され、OWASP Top 10:2025 として公開されました。
今回の改訂では、カテゴリの順位が入れ替わっただけでなく、2つのカテゴリが新設され、これまで独立項目だったSSRFが姿を消すという構造的な変化が起きています。脆弱性診断の発注仕様やセキュリティ要件定義に「OWASP Top 10に準拠」と書いている企業にとっては、参照先の中身が変わったことを意味します。
本記事では、OWASP Top 10:2025の全10カテゴリと2021年版からの変更点を整理したうえで、実際の脆弱性診断で「どこまで確認できて、どこからが確認できないのか」という実務上の論点まで解説します。
OWASP Top 10:2025とは
OWASP Top 10とは、OWASP（Open Worldwide Application Security Project）という非営利団体が公開している、Webアプリケーションにおける重大なセキュリティリスクの上位10項目をまとめた文書です。特定の製品やベンダーに依存しない中立的な基準であるため、脆弱性診断の診断項目、セキュリティ要件定義、開発者教育のカリキュラムなど、幅広い場面でデファクトスタンダードとして使われています。
2025年版は2025年11月にワシントンD.C.で開催されたOWASP Global AppSec Conferenceで発表され、2026年1月に正式版がリリースされました。
2025年版の作成方法
2025年版は、589のCWE（共通脆弱性タイプ一覧）を対象に、約280万件のアプリケーションから収集されたテストデータをもとに集計されています。ただしOWASP自身が「データに基づくが、データに盲従はしない（data-informed, but not blindly data-driven）」と述べているとおり、10カテゴリのうち8つは実測データから、残る2つはコミュニティ投票から選出されています。
これは、自動化されたテストで検出しやすい脆弱性ばかりが上位に来てしまうという構造的な偏りを補正するための仕組みです。実際、設計上の問題や業務ロジックの欠陥は自動テストで数えにくいため、データだけに頼ると過小評価されます。この点は、後述する「診断で見つかるもの・見つからないもの」とも深く関係します。
2021年版からの変更点【対応表】
まず全体像を対応表で確認します。
2025年版 | カテゴリ名 | 2021年版での位置 |
|---|---|---|
A01 | アクセス制御の不備（Broken Access Control） | A01（1位維持） |
A02 | セキュリティ設定の不備（Security Misconfiguration） | A05から上昇 |
A03 | ソフトウェアサプライチェーンの不備（Software Supply Chain Failures） | 新設（A06を拡張） |
A04 | 暗号化の不備（Cryptographic Failures） | A02から下降 |
A05 | インジェクション（Injection） | A03から下降 |
A06 | 安全でない設計（Insecure Design） | A04から下降 |
A07 | 認証の不備（Authentication Failures） | A07（名称変更） |
A08 | ソフトウェアまたはデータの完全性の不備 | A08 |
A09 | セキュリティログおよびアラートの不備 | A09（名称変更） |
A10 | 例外状態の不適切な処理（Mishandling of Exceptional Conditions） | 新設 |
新設された2つのカテゴリ
A03：ソフトウェアサプライチェーンの不備は、2021年版の「A06：脆弱で古くなったコンポーネント」を大幅に拡張したものです。単に「使っているライブラリが古い」という話にとどまらず、ビルド環境、CI/CDパイプライン、パッケージ配布経路、依存関係の解決プロセスまでを含むリスクとして再定義されました。Log4ShellやSolarWinds事件以降、攻撃者が個々のアプリではなく供給網そのものを狙うようになった実態を反映した変更です。
このカテゴリへの対応では、自社が何を使っているかを把握する仕組みが前提になります。詳しくはSBOMとは？意味・3フォーマットの違い・導入5ステップで解説しています。
A10：例外状態の不適切な処理は完全な新設カテゴリで、24のCWEが含まれます。想定外の入力、処理の失敗、タイムアウト、外部サービスの障害といった「異常が起きたとき」にシステムが安全側に倒れるかを問うものです。典型的な問題がフェイルオープン、つまり認証サーバーが応答しないときに認証を通してしまう、決済APIがタイムアウトしたときに注文を確定させてしまう、といった挙動です。正常系のテストでは決して現れず、攻撃者が意図的に異常を起こして初めて表面化します。
SSRFはどこへ行ったのか
2021年版でA10だったSSRF（サーバーサイドリクエストフォージェリ）は、2025年版では独立カテゴリから外れ、A01のアクセス制御の不備に統合されました。「サーバーに本来行うべきでない通信を行わせる」ことは、その本質がアクセス制御の失敗であるという整理です。
マイクロサービスやクラウドサービス、APIの多用によって、サービス間の権限とユーザーの権限の境界が曖昧になっている現状を踏まえた変更といえます。SSRFの重要度が下がったわけではないため、診断仕様書に「SSRFを含む」と明記していた場合は、A01の範囲として読み替える必要があります。
A01が4年連続で1位である意味
アクセス制御の不備は2021年版に続き1位を維持しました。OWASPの集計では、テスト対象アプリケーションの平均3.73%でこのカテゴリに属する40のCWEのいずれかが検出されています。2025年版ではさらに、API時代の主要な攻撃パターンであるBOLA（オブジェクトレベルの認可不備）とBFLA（機能レベルの認可不備）が明示的に含まれるようになりました。
アクセス制御の不備が上位に居座り続けるのは、これが「そのシステムの仕様を知らないと正しさを判定できない」タイプの問題だからです。ツールは「Aさんのデータが見えている」という事実を検出できても、それが仕様上正しいのか誤りなのかを判断できません。
OWASP Top 10:2025 全10カテゴリ解説
A01：アクセス制御の不備
本来アクセスを許可されていない利用者が、他の利用者の情報や管理機能へアクセスできてしまう問題です。URLやIDの書き換えによる他ユーザー情報の閲覧・変更、一般ユーザーから管理者機能への到達、権限昇格、組織・部署・契約者間のデータ分離の失敗などが含まれます。2025年版からはSSRFもここに含まれます。
A02：セキュリティ設定の不備
Webサーバー、アプリケーション、HTTP通信などの設定に起因する問題です。セキュリティヘッダーの不足、Content-Security-PolicyやStrict-Transport-Securityの未設定、Cookie属性の不備、不要なHTTPメソッドの許可、ディレクトリリスティング、管理画面やテストページの公開、サーバーバージョン情報の露出、バックアップファイルの放置などが該当します。2021年版の5位から2位へ上昇しました。
A03：ソフトウェアサプライチェーンの不備
使用しているソフトウェア、ライブラリ、フレームワークに既知の脆弱性がある、あるいは供給経路そのものが信頼できないという問題です。外部JavaScriptやCDNの読み込み、Subresource Integrityの未設定、依存コンポーネントの情報露出などが外部から確認できる代表的な兆候です。
A04：暗号化の不備
通信内容、認証情報、個人情報などが適切に保護されているかという問題です。TLSバージョンや暗号スイートの妥当性、証明書の有効性、HTTPとHTTPSの混在、Secure属性のないCookie、URL上への機密情報の露出、予測可能なトークンや識別子などが含まれます。
A05：インジェクション
入力値を利用して、データベースやサーバーに不正な命令を実行させる問題です。SQLインジェクション、OSコマンドインジェクション、クロスサイトスクリプティング、HTTPヘッダーインジェクション、CRLFインジェクション、XML外部実体参照などが含まれます。長年トップ3の常連でしたが、フレームワーク側での対策が普及したことを反映して5位まで下がりました。
A06：安全でない設計
実装のバグではなく、システムの設計や業務処理そのものに問題があるケースです。本来の処理順序を無視した操作、画面遷移や承認処理の迂回、二重送信、利用回数制限の回避、金額や数量の改ざん、クーポンやポイントの不正利用などが該当します。実装が仕様どおりでも、仕様自体が危険であれば脆弱性になるという考え方です。
A07：認証の不備
ログイン機能や本人確認機能が適切に実装されているかという問題です。認証処理の回避、アカウントの存在推測、パスワードポリシーやアカウントロックの不備、ブルートフォース攻撃への耐性、パスワードリセット機能の弱さ、多要素認証の回避、セッション固定、ログアウト後のセッション無効化などが含まれます。2025年版で「Identification and Authentication Failures」から名称が簡素化されました。
A08：ソフトウェアまたはデータの完全性の不備
外部から取得するデータ、更新ファイル、処理データが不正に改ざんされないかという問題です。Hidden項目やCookie・トークンの改ざん、署名値やハッシュ値の検証不足、リクエストの再送信によるリプレイ攻撃、Webhookの署名検証漏れ、安全でないデシリアライゼーションなどが含まれます。
A09：セキュリティログおよびアラートの不備
不正アクセスや異常操作が適切に記録され、必要な担当者へ通知される仕組みがあるかという問題です。2021年版の「監視（Monitoring）」から「アラート（Alerting）」へ名称が変更され、記録するだけでなく気づけるかに力点が移りました。認証失敗時の挙動、連続した異常操作への制限、攻撃試行時のシステム応答などが評価対象になります。
A10：例外状態の不適切な処理
想定外の入力、処理失敗、タイムアウトなどが発生した場合に安全に処理されるかという新設カテゴリです。境界値・異常値・NULL・負数・巨大値の扱い、処理の中断と再実行、通信切断時のデータ整合性、外部サービス障害時の挙動、エラー発生時の機密情報露出などが対象になります。
診断で「見つかるもの」と「見つからないもの」
ここからが実務上、最も重要な論点です。「OWASP Top 10に準拠した診断」と一口に言っても、診断の方式によってカバーできる範囲はカテゴリごとに大きく異なります。脆弱性診断の見積もりが数十万円から数百万円まで開くのは、多くの場合この差が原因です。
外部からのブラックボックス診断を前提に、自動診断ツールのみの場合と、自動診断にセキュリティエンジニアの手動診断を加えた場合とで、カテゴリごとの確認深度を整理すると次のようになります。
カテゴリ | 自動診断のみ | 自動＋手動診断 |
|---|---|---|
A01 アクセス制御の不備 | △ | ◎ |
A02 セキュリティ設定の不備 | ○ | ◎ |
A03 ソフトウェアサプライチェーンの不備 | △ | ○ |
A04 暗号化の不備 | ○ | ◎ |
A05 インジェクション | ○ | ◎ |
A06 安全でない設計 | △ | ◎ |
A07 認証の不備 | △ | ◎ |
A08 完全性の不備 | △ | ○ |
A09 ログ・アラートの不備 | △ | ○ |
A10 例外状態の不適切な処理 | ○ | ◎ |
◎はエンジニアがシステム仕様を踏まえて詳細に確認できる範囲、○は一般的な項目を確認できる範囲、△は外部から確認可能な範囲に限定されることを示します。
自動診断だけでは埋まらない3つの空白
表を見ると、△が集中しているカテゴリには共通点があります。
1つ目は「仕様を知らないと正誤を判定できない」カテゴリです。A01のアクセス制御、A07の認証、A06の安全でない設計がこれに当たります。ツールは「操作ができてしまった」ことは検出できても、それが許された操作なのかを知りません。他部署のデータが見えることが業務上正しい設計なのか、あってはならない情報漏えいなのかは、システムの利用ルールを理解して初めて判断できます。
2つ目は「攻撃が実際に成立するかの検証が必要」なカテゴリです。自動診断ツールは既知の攻撃パターンに反応するため、誤検知を含みます。逆に、複数のパラメータを組み合わせた攻撃や、WAFや入力制限を回避する手法は、機械的な巡回では到達できません。検出結果を並べるところまでは自動化できても、危険度の評価には人の精査が要ります。
3つ目は「外部からは見えない」カテゴリです。A03のサプライチェーン、A09のログ・アラートがこれに該当します。外部診断ではビルド環境やCI/CD、内部のログ保存状況を直接確認できません。ここを詰めるには、ソフトウェア構成表やSBOM、設定資料、運用担当者へのヒアリングが必要になります。この制約は手動診断を追加しても完全には解消しません。診断の限界を正しく理解し、報告書に「確認できなかった項目」が明記されているかを確認することが重要です。
発注時に確認すべきこと
見積もりを比較する際は、金額だけでなく次の点を揃えて確認すると、同じ土俵で比べられます。
- どのOWASPカテゴリを、どの深度（◎○△）で確認するのか
- 自動診断の検出結果をエンジニアが精査するのか、そのまま報告されるのか
- 誤検知の除外が含まれるか
- 攻撃が実際に成立するかの検証を行うか
- 確認できなかった項目と制限事項が報告書に明記されるか
- 改修後の再診断が含まれるか、その適用条件は何か
費用の相場観についてはWebアプリ脆弱性診断 費用・相場ガイド【2026年版】で種別・規模別に整理しています。また、脆弱性診断とペネトレーションテストは目的が異なるため、混同しやすい方は脆弱性診断とペネトレーションテストの違いもあわせてご覧ください。
2025年版への移行で企業がまずやるべき3つのこと
1. 診断仕様書・要件定義の参照バージョンを更新する
「OWASP Top 10に準拠」とだけ書かれている文書は、どの版を指すのかが曖昧になります。2025年版を参照するのか、当面2021年版を維持するのかを明示してください。特にSSRFを個別項目として列挙していた場合は、A01に統合された点の反映が必要です。
2. 新設2カテゴリの現状を棚卸しする
A03のサプライチェーンとA10の例外状態は、これまでの診断でカバーされていない可能性が高い領域です。まずは自社が使っている外部コンポーネントを一覧化できているか、異常系のテストが実施されているかを確認するところから始められます。
3. 既存の診断結果を新カテゴリで読み替える
過去の診断報告書は2021年版の分類で書かれています。順位が変わったA02（設定の不備）は、以前より重要度が高いリスクとして扱われるようになりました。過去に「低」と評価して放置している指摘があれば、再評価の価値があります。
APIを含む診断を検討している場合は、API脆弱性診断の進め方もあわせて参考にしてください。AEVUSでは、自動診断ツールによる網羅的な検査と、セキュリティエンジニアによる手動診断を組み合わせたWebアプリケーション脆弱性診断を提供しています。
よくある質問
Q1. OWASP Top 10:2025はいつ公開されましたか？
A. 2025年11月にワシントンD.C.のOWASP Global AppSec Conferenceで発表され、2026年1月に正式版がリリースされました。2021年版から約4年ぶりの更新です。
Q2. 2021年版はもう使ってはいけませんか？
A. 使ってはいけないわけではありません。ただし2025年版では新設カテゴリが2つあり、SSRFの扱いも変わっているため、参照している版を文書内に明記しておくことが重要です。契約や仕様書で「最新版に準拠」と書いていた場合は、実質的に2025年版を指すことになります。
Q3. SSRFは2025年版でなくなったのですか？
A. なくなったわけではなく、A01のアクセス制御の不備に統合されました。サーバーに意図しない通信を行わせることは本質的にアクセス制御の失敗である、という整理によるものです。診断対象からは外れません。
Q4. 新設されたA10「例外状態の不適切な処理」とは何ですか？
A. 想定外の入力や処理失敗、タイムアウトが発生したときに、システムが安全側に倒れるかを問うカテゴリです。認証サーバーが応答しないときに認証を通してしまうフェイルオープンのような挙動が典型例で、正常系のテストでは表面化しません。
Q5. 自動診断ツールだけでOWASP Top 10すべてをカバーできますか？
A. できません。自動診断ツールはシステムの業務仕様や利用者権限を理解できないため、アクセス制御・認証・安全でない設計といったカテゴリでは外部から確認可能な範囲に限定されます。また、サプライチェーンやログ・アラートは外部診断そのものに限界があり、資料確認や内部環境へのアクセスが必要になります。
まとめ
OWASP Top 10:2025では、ソフトウェアサプライチェーンの不備と例外状態の不適切な処理という2つのカテゴリが新設され、SSRFがアクセス制御へ統合されました。順位の面では、セキュリティ設定の不備が5位から2位へ上昇し、インジェクションが3位から5位へ後退しています。
一方で、アクセス制御の不備が引き続き1位である点は変わりません。これはツールでは正誤を判定できない、仕様の理解が必要な脆弱性が依然として最大のリスクであることを示しています。診断を「OWASP Top 10準拠」と表現するだけでは、実際にどこまで確認されるのかは決まりません。カテゴリごとの確認深度まで踏み込んで仕様を定義することが、投じた費用を成果に変える近道です。
まずは自社の診断仕様書が参照している版を確認し、新設された2カテゴリが現在の診断範囲に含まれているかを点検するところから始めてみてください。
