OWASP Top 10とは何か？
開発者が金曜日の午後にコードをプッシュします。月曜日までに、攻撃者はAPIパラメータを操作し、顧客記録にアクセスし、単純な認可チェックで防げたアクセス制御の不備を悪用して情報を流出させました。これはOWASP Top 10が防止を目的とする脆弱性の一例です。
OWASP FoundationはOWASP Top 10を「開発者およびWebアプリケーションセキュリティのための標準的な認識文書」と定義しています。これはWebアプリケーションに対する最も重大なセキュリティリスクについての幅広い合意を示しています。このリストは複数回改訂されており、2025年版ではアプリケーションセキュリティの状況変化を反映した構造的な変更が導入されました。
NISTおよびMITRE CWEコンテンツチームは、自身のフレームワークでOWASP Top 10カテゴリを正式に参照しています。セキュリティプログラムを運用している場合、アプリケーションを構築している場合、または脆弱性対応を管理している場合、OWASP Top 10は関係者が対応を期待する基準となります。以下は現行版の内容と、各カテゴリが環境にどのように適用されるかの説明です。
2025年版 OWASP Top 10 カテゴリ
2025年版では実際のデータに基づき優先順位が再編成されました。以下は現時点での全10カテゴリと、セキュリティプログラムに影響する主な変更点です。
A01: アクセス制御の不備
依然として最上位のカテゴリであり、テストされたアプリケーションの3.73%で少なくとも1つの関連する不備が確認されています。Broken access controlは、ユーザーが本来の権限を超えて操作できる状態を指します。たとえば、URLパラメータの改変による他ユーザーの記録閲覧、JWTトークンの操作による権限昇格、機能レベルの制限回避などです。これにはinsecure direct object references (IDOR)、アクセス制御の欠如、CORS設定ミスが含まれます。以前は独立カテゴリだったSSRFもここに統合されました。
A02: セキュリティ設定ミス
2021年の#5から順位が上昇し、現代のアプリケーション動作がコードよりも設定に依存していることを反映しています。このカテゴリは、デフォルト認証情報の未変更、不要なサービスの公開、スタックトレースを漏らす冗長なエラーメッセージ、セキュリティヘッダーの欠如などを含みます。クラウド環境やコンテナ化されたデプロイメントでは、各サービスやAPIゲートウェイ、Kubernetesクラスターごとに設定面のリスクが増大します。
A03: ソフトウェアサプライチェーンの不備
2025年版で最も顕著な構造的変更です。以前は「脆弱または古いコンポーネント」に限定されていましたが、現在はソフトウェア依存関係、ビルドシステム、配布インフラ全体を対象としています。攻撃者はアプリケーションコードそのものではなく、CI/CDパイプライン、開発ツール、コンテナレジストリ、広く利用されるオープンソースパッケージを標的にする傾向が強まっています。発生件数は少ないものの、このカテゴリは2025年データセットで最も高い平均exploitおよび影響スコアを持ちます。
A04: 暗号化の不備
「機微データの露出」から名称変更され、症状ではなく根本原因に焦点を当てています。このカテゴリは、平文でのデータ送信、非推奨ハッシュ関数（MD5、SHA1）、パスワードを暗号鍵として使用、不十分な乱数生成などを含みます。暗号保護が失敗すると、攻撃者は通信中の認証情報を傍受したり、保存データを復号したり、認証トークンを偽造できます。名称変更は、露出事象の事後的なカタログ化ではなく、なぜデータが露出するのかという根本原因への対応を重視するOWASPの方針転換を反映しています。
A05: インジェクション
インジェクションは、アプリケーションが信頼できない入力を適切な検証やエスケープなしにインタプリタへ渡すことで、攻撃者が意図しないコマンドを実行できる状態です。 SQLインジェクション、 クロスサイトスクリプティング（XSS）、OSコマンドインジェクション、LDAPインジェクションなどが該当します。2025年版で#3から#5に順位が下がりましたが、関連CVE数は依然として多く、入力処理が不十分な場合は主要な情報漏洩原因となります。
A06: 設計上の不備
このカテゴリは実装バグではなく、アーキテクチャや設計レベルの欠陥に対応します。弱いパスワードリセットフロー、業務フローでの認可ステップの欠如、重要エンドポイントでのレート制限の未実装などは設計上の判断であり、安全なコーディングだけでは根本的な設計不備は修正できません。OWASPは脅威モデリング、安全な設計パターン、コーディング前のセキュリティ活動を重視するためにこのカテゴリを導入しました。2025年版で#4から#6に順位が下がったことは、業界全体での改善傾向を示しています。
A07: 識別および認証の不備
このカテゴリは、攻撃者がユーザーIDを侵害できる弱点を対象とします。クレデンシャルスタッフィング、弱いパスワードへのブルートフォース攻撃、 多要素認証（MFA）の未実装、予測可能なセッショントークンや不適切な無効化などのセッション管理の不備が含まれます。OWASPの分析によれば、標準化された認証フレームワークの利用増加が発生率の改善に寄与していますが、盗まれた認証情報は依然として侵害の初期アクセス経路として一般的です。
A08: ソフトウェアまたはデータの完全性の不備
このカテゴリは、ソフトウェアアップデート、CI/CDパイプライン、データシリアライズにおける信頼の前提を対象とします。アプリケーションが署名検証なしで自動更新を行ったり、未検証ソースから依存関係を取得したり、検証なしで信頼できないデータをデシリアライズする場合、攻撃者は悪意のあるコードをアプリケーション権限で実行させることができます。また、CI/CDパイプラインの完全性も対象で、ビルドステップが侵害されると悪意のあるアーティファクトが検知されず本番環境に配布されるリスクがあります。
A09: セキュリティログおよびアラートの不備
「セキュリティログおよび監視の不備」からの名称変更は意図的です。OWASPの 2025年版序文によれば、「優れたログがあってもアラートがなければ、インシデント特定にはほとんど価値がない」とされています。ログソースに紐づく実用的なアラートがなければ、証拠が保存されていても侵害は見逃されます。このカテゴリは、ログ詳細の不足、機微操作の監査証跡の欠如、認証やアクセス制御イベントを記録しないログも対象です。
A10: 例外的状況の不適切な処理
2025年版で新設されたカテゴリであり、アプリケーションが予期しない入力、リソース不足、タイムアウト、内部障害に遭遇した際の挙動を対象とします。不適切な例外処理は、冗長なスタックトレースによる機微データ漏洩、フェイルオープンロジックによるセキュリティ制御の回避、サービス拒否状態の発生などを引き起こします。OWASPは、従来「コード品質」問題として分散していた24のCWEをこのカテゴリに統合し、安全でない障害が独立したリスクであるという認識の高まりを反映しています。
以下の表は、各カテゴリと2025年版での変更点をまとめたものです。
| # | カテゴリ | 2025年の変更点 |
| A01 | アクセス制御の不備 | 以前は独立カテゴリだったSSRFを統合 |
| A02 | セキュリティ設定ミス | 2021年の#5から順位上昇 |
| A03 | ソフトウェアサプライチェーンの不備 | 「脆弱または古いコンポーネント」から依存関係全体に拡大 |
| A04 | 暗号化の不備 | #2から順位低下、根本的な暗号化問題に引き続き注力 |
| A05 | インジェクション | #3から#5に順位低下、依然としてテスト対象が多いカテゴリ |
| A06 | 設計上の不備 | #4から#6に順位低下、脅威モデリングの普及が進展 |
| A07 | 認証の不備 | 順位は変わらず、「識別および認証の不備」から名称微修正 |
| A08 | ソフトウェアまたはデータの完全性の不備 | 順位は変わらず |
| A09 | セキュリティログおよびアラートの不備 | 名称変更、「アラート」が「監視」に代わり運用ニーズを反映 |
| A10 | 例外的状況の不適切な処理 | 新カテゴリ、従来のSSRFエントリを置換 |
これらのカテゴリが基準となります。各カテゴリの修正方法を見る前に、なぜこれらのリスクが組織にとって重要なのかを理解することが役立ちます。
OWASP Top 10が重要な理由
脆弱性発見から悪用までのギャップは縮小し続けており、Webアプリケーションは依然として主要な侵入経路です。組織にとってOWASP Top 10が重要な理由は3つあります。
- リスクの優先順位付け。すべてを同時に修正することはできません。Top 10は、理論的な深刻度だけでなく、悪用可能性と影響度に基づくデータ駆動型の出発点を提供します。
- 規制対応。 NIST CSFはOWASP Top 10のバリアントへのクロスウォークマッピングを維持しています。監査人や規制当局がアプリケーションセキュリティプログラムについて質問する際、OWASP Top 10は共通言語となります。
- 財務的現実。アクセス制御、設定ミス、インジェクションにおけるセキュリティ不備は高額なインシデントにつながる可能性があります。OWASP Top 10は、運用やビジネスに影響を与える可能性が高い脆弱性クラスにチームの注力を促します。
なぜこれらのリスクが重要なのかを理解することが第一歩です。次は、各リスクにコードや設定レベルでどのように対処するかを知ることです。
OWASP Top 10脆弱性の防止方法
OWASP Top 10の各カテゴリには、チームが直接実装できる具体的な防止策があります。
- A01: アクセス制御の不備。すべてのエンドポイントでデフォルト拒否を徹底します。すべてのリクエストでサーバー側で権限を検証し、コードベース全体で一貫して適用される単一のアクセス制御ルーチンに統合します。ディレクトリリスティングを無効化し、CORSポリシーで信頼できるドメインのみに制限します。
- A02: セキュリティ設定ミス。デフォルト認証情報を削除し、未使用のサービスや機能を無効化し、環境全体で設定監査を自動化します。セキュリティヘッダーを最新に保ち、エラーメッセージはスタックトレースではなく汎用的な応答を返すようにします。
- A03: ソフトウェアサプライチェーンの不備。依存関係は特定バージョンに固定し、暗号署名やチェックサムで完全性を検証します。ソフトウェア部品表（SBOM）を維持し、CI/CDプラグインや開発ツールを監査し、依存ツリー内の既知の脆弱性について脆弱性データベースを監視します。
- A04: 暗号化の不備。最新の暗号化標準（TLS 1.2+、AES-256）を使用し、MD5やSHA1などの非推奨アルゴリズムは廃止します。パスワードはbcryptやArgon2などの適応型ハッシュ関数で保存します。データを機微度で分類し、適切な保護レベルを適用します。
- A05: インジェクション。すべてのデータベース操作でパラメータ化クエリを使用します。すべてのユーザー入力を検証・サニタイズし、出力はレンダリングコンテキスト（HTML、JavaScript、SQL）ごとにエスケープします。コンテンツセキュリティポリシーを適用し、XSSの影響を低減します。
- A06: 設計上の不備。コーディング前に脅威モデリングを実施し、機能テストと並行して悪用ケーステストを確立し、OWASP Proactive Controlsの安全な設計パターンを適用します。設計不備はアーキテクチャ段階で修正する方が本番環境よりもコストが低くなります。
- A07: 認証の不備。MFAを強制し、ログイン試行回数の制限付きスロットリングを実装し、標準化された認証フレームワークを使用します。ログアウトやパスワード変更時にはセッションを適切に無効化します。
- A08: ソフトウェアまたはデータの完全性の不備。すべてのビルドアーティファクト、コンテナイメージ、ソフトウェアアップデートに暗号署名を施します。デシリアライズ入力を検証し、CI/CDパイプラインの書き込み権限は認可されたロールのみに制限します。
- A09: セキュリティログおよびアラートの不備。認証失敗、アクセス制御違反、権限昇格試行に対して実用的なアラート閾値を設定します。ログが取り込まれるだけでなく、実際の条件下でアラートが発火することをテストします。
- A10: 例外的状況の不適切な処理。エラー時にアクセスを拒否する安全なフェイルモードを定義します。ユーザーには汎用的なエラーメッセージを返し、詳細な診断情報は内部ログに記録します。null値、リソース枯渇、予期しない入力型を明示的に処理します。
カテゴリごとの防止策は技術的な修正に対応します。これらの修正を組織全体に拡大する際に実装上の課題が生じます。
OWASP Top 10実装における課題とよくある誤り
数百のアプリケーション、複数の開発チーム、継続的デプロイメントサイクルを持つ本番環境でOWASP Top 10を運用化する際、実装が破綻しやすくなります。以下は最も大きな損害をもたらすパターンです。
- Top 10を合否チェックリストとして扱う。OWASPはTop 10を 認識ガイドであり、セキュリティプログラムそのものではないと明記しています。検証レベルのテストにはOWASP ASVSが推奨されており、サプライチェーン対策だけであればTop 10は「時折」十分とされています。
- 分散したアクセス制御実装。 Proactive Controlsプロジェクトは、コードベース内に複数のアクセス制御実装が分散していることの危険性を警告しています。1つでも不備があれば、他が正しくても攻撃可能なままです。
- デフォルト許可の設定。REST APIやWebhookでデフォルト拒否を徹底しない場合、未対応エンドポイントが暗黙的にアクセス可能となります。これはクラウドサービス、KubernetesのRBAC、APIゲートウェイにも当てはまります。
- 大規模な認可管理。認証は改善していますが、アクセス制御はそうではありません。業界は「あなたは誰か？」には対応しつつありますが、「何を許可すべきか？」にはAPIやマイクロサービス全体で苦戦しています。
- アラートのないログ記録。大量のログデータをSIEMに取り込んでいても、実用的なアラート閾値が設定されていなければ、証拠が保存されていてもインシデントは見逃されます。
- 列挙型スキャンへの過度な依存。列挙型ツールは既知の問題しか検出できません。論理的な不備、新種の設定ミス、アーキテクチャ上の弱点は、シグネチャマッチングだけでなく、挙動分析が必要です。
これらのパターンは、セキュリティプログラムがOWASP Top 10を一度きりの監査として扱い、継続的な運用実践としない場合に継続します。
OWASP Top 10のベストプラクティス
カテゴリごとの修正に加え、以下のプログラムレベルの実践がOWASP Top 10の運用化に役立ちます。
- セキュリティ制御の集中管理ライブラリを構築。 プログラムガイダンスに従い、認証、認可、入力検証、暗号化のための共有・再利用可能なライブラリを定義します。各チームが独自実装を行うと、不整合が攻撃可能なギャップを生みます。
- Proactive Controlsを開発ワークフローにマッピング。 Proactive Controlsは、リスク中心のTop 10を補完する開発者向けガイドです。C1（アクセス制御）はA01、C3（入力検証）はA05、C5（安全なデフォルト）はA02に対応します。開発者には回避すべきリスクではなく、実装すべき具体的制御を提示します。
- OWASP ASVSを検証基準として使用。アドホックなペネトレーションテストをやめ、各Top 10カテゴリにマッピングされた構造化された ASVS要件を利用します。ASVSはCSVやJSON形式のテスト基準を提供し、プログラム的な統合が可能です。
- 規制対応のためNIST SSDFと統合。 NIST SP 800-218はOWASP ASVS、OWASP SAMM、OWASP SCVSを補完的フレームワークとして明記し、大統領令14028の要件とも整合しています。
これらの実践がプログラムの基盤を形成します。テストによって防止制御が期待通りに機能することを検証します。
OWASP Top 10のテスト方法
すべてのカテゴリをカバーする単一ツールは存在しません。効果的なOWASP Top 10テストは、静的解析、動的テスト、構成解析を組み合わせ、コードレベル、実行時、依存関係リスクを網羅します。
- 静的アプリケーションセキュリティテスト（SAST）は、デプロイ前にソースコードをスキャンし、インジェクションパターン、暗号化の弱点、認証の不備を検出します。SASTは開発初期段階での修正が最も安価なタイミングで問題を発見します。
- 動的アプリケーションセキュリティテスト（DAST）は、実行中のアプリケーションに対して実際の攻撃トラフィックをシミュレートし、アクセス制御の抜け穴、設定ミス、エラー処理の不備を検出します。OWASP ZAPはOWASPコミュニティが維持する広く利用されているオープンソースDASTツールです。
- ソフトウェア構成解析（SCA）は、サードパーティライブラリ、フレームワーク、コンテナイメージ内の既知の脆弱性を、依存ツリーを公開脆弱性データベースと照合することで特定します。
- ペネトレーションテストは、特定の環境に対して自動ツールが見逃す論理的不備やアーキテクチャ上の弱点を検出します。ペネトレーションテストの結果は ASVS要件にマッピングし、構造化された検証を行います。
以下の表は、各テスト手法がOWASP Top 10のどのカテゴリを主にカバーするかを示しています。
手法 | カバーするカテゴリ | 最適な利用タイミング |
SAST | A04, A05, A07 | 開発中、コードマージ前 |
| DAST | A01, A02, A10 | ステージングまたは本番環境での実行中アプリケーションに対して |
| SCA | A03, A08 | ビルド時および依存関係更新ごと |
| ペネトレーションテスト | 全10カテゴリ | 定期的な検証、大規模リリース後 |
これらの手法を組み合わせることで、OWASP Top 10全カテゴリをカバーできます。自律型ツールは、発見から対応までのギャップを埋める役割を果たします。
まとめ
OWASP Top 10は、Webアプリケーションセキュリティリスクに関する業界標準の認識フレームワークであり、2025年版ではサプライチェーンの拡大やログ記録と並ぶアラートへの新たな注力が加わりました。アクセス制御の不備が依然として最上位カテゴリです。各カテゴリには、デフォルト拒否のアクセス制御から暗号化アーティファクトの検証まで、具体的かつ実装可能な防止策があります。
効果的な実装には、セキュリティ制御の集中管理、SAST・DAST・SCAによる多層的テスト、そして悪用速度と対応速度のギャップを埋める自律的な調査が必要です。
FAQ
OWASP Top 10は、OWASP Foundationが公開している標準的な啓発ドキュメントであり、Webアプリケーションに対する最も重大なセキュリティリスクを特定しています。
実際の脆弱性データやコミュニティ調査に基づき、開発者、セキュリティチーム、監査担当者がアプリケーションセキュリティプログラムの基準として利用する、コンセンサスに基づくランキングを提供します。現行版は2025年にリリースされました。
OWASP Top 10には固定のリリーススケジュールはありません。十分な新しい脆弱性データとコミュニティからの意見が集まった際に、ランキングの改訂が公開されます。
過去のエディションは2013年、2017年、2021年、2025年にリリースされました。各更新は、実際の悪用傾向の変化、アプリケーションアーキテクチャの変化、新しいデータ収集手法の導入など、理論的なリスク予測だけでなく現実の変化を反映しています。
Top 10は、Webアプリケーションにおける最も重大なリスクカテゴリを強調するための啓発ドキュメントです。ASVS（Application Security Verification Standard）は、3つの保証レベルで構造化されたテスト可能な検証要件を提供し、セキュリティテストやコードレビューに適しています。
OWASP自身も、設計レビューやセキュリティ評価にはASVSの利用を推奨しており、Top 10はエントリーポイント、ASVSは検証フレームワークとして位置付けられています。
WebアプリケーションのTop 10は、特にBroken Access Control（A01）やInjection（A05）など、APIに関連するカテゴリをカバーしています。しかし、OWASPはAPIの認可、レート制限、オブジェクトレベルのアクセス制御など、API固有のカテゴリを含む別のAPIセキュリティTop 10を維持しています。
主要なAPIリスクのいくつかは、A01と同様の認可の失敗に直接関連しています。APIの利用が多い組織は、十分なカバレッジを確保するために両方のリストに対応する必要があります。
2025年の手法では、分析対象のデータセットが拡大され、OWASPのコミュニティ調査コンポーネントとともに、より広範なデータ提供サイクルが導入され、将来を見据えたリスクが考慮されました。
重み付けの計算式は、引き続き悪用可能性と技術的影響のバランスを取りつつ、より広範な脆弱性コーパスを反映しました。この手法の拡張により、単なる脅威パターンの変化だけでなく、Security Misconfigurationの順位上昇やMishandling of Exceptional Conditionsの新カテゴリ追加など、いくつかのランキング変更がもたらされました。
いいえ。OWASPはTop 10が啓発および入門レベルのトレーニングツールであることを明確に示しています。サプライチェーンセキュリティに関しても、Top 10は「場合によっては」十分とされています。
完全なプログラムには、検証のためのOWASP ASVS、成熟度評価のためのOWASP SAMM、SDLC統合のためのNIST SSDF、そしてTop 10ではカバーされないリスクに対応するための継続的なランタイム保護を組み込む必要があります。
