はじめに

2025年末に「OWASP Top 10 2025」が正式リリースされました。
本記事では、「OWASP Top 10 2021」（以下、2021年版）から「OWASP Top 10 2025」（以下、2025年版）への主な変更内容について抜粋してご紹介します。

OWASP Top 10について

OWASP Top 10は、Webアプリケーションにおける最も重要なセキュリティリスクを10のカテゴリに分類し、意識向上を目的としてまとめられた文書です。 Webアプリケーションにおけるセキュリティの最低限の基準として位置付けられています。
コーディングやテストにおけるセキュリティ要件にはOWASP ASVSを推奨しており、開発のセキュリティ体制の評価にはOWASP SAMMやOWASP DSOMMの使用を検討するよう言及されています。
他にも各カテゴリでは参考文献として複数の資料が挙げられています。OWASPやNISTの資料を紹介しますので適宜ご参照ください。

また、OWASP Top 10では下記の文書も公開されています。

2021年版から2025年版におけるカテゴリの変更点

2025年版ではカテゴリ構造に下記の変更があります。

「Next Steps」を含む2021年版から2025年版におけるカテゴリの変更点は下記となります。

2021年版	2025年版	変更点の概要
A01:2021 - Broken Access Control	A01:2025 - Broken Access Control	順位維持、A10を統合
A02:2021 - Cryptographic Failures	A02:2025 - Security Misconfiguration	5位→2位に変更
A03:2021 - Injection	A03:2025 - Software Supply Chain Failures	A06を拡張し新規追加
A04:2021 - Insecure Design	A04:2025 - Cryptographic Failures	2位→4位に変更
A05:2021 - Security Misconfiguration	A05:2025 - Injection	3位→5位に変更
A06:2021 - Vulnerable and Outdated Components	A06:2025 - Insecure Design	4位→6位に変更
A07:2021 - Identification and Authentication Failures	A07:2025 - Authentication Failures	順位維持、名称変更
A08:2021 - Software and Data Integrity Failures	A08:2025 - Software or Data Integrity Failures	順位維持、名称変更
A09:2021 - Security Logging and Monitoring Failures	A09:2025 - Security Logging & Alerting Failures	順位維持、名称変更
A10:2021 - Server-Side Request Forgery	A10:2025 - Mishandling of Exceptional Conditions	新規追加
Code Quality issues	X01:2025 Lack of Application Resilience	名称変更
Denial of Service	X02:2025 Memory Management Failures	名称変更
Memory Management Errors	X03:2025 Inappropriate Trust in AI Generated Code (‘Vibe Coding’)	新規追加

ここからは、変更点を下記の5つに分けて詳細を解説していきます。

1. 「A01:2025 - Broken Access Control」のカテゴリ統合

2021年版	2025年版
1位	1位

2021年版で独立したカテゴリであった「A10:2021 - Server-Side Request Forgery」（以下、SSRF）が統合された「A01:2025 - Broken Access Control」は、2021年版に引き続き2025年版でも1位となりました。
SSRFは2021年版において調査データ上の発生率が低かったものの、コミュニティ調査上では1位にランキングされたことから選出されており、単一のCWEとして独立したカテゴリとなっていました。しかし、将来的にはより大きなカテゴリに統合されることが期待されていました。
2025年版にて本カテゴリへ統合されたことは、細工したリクエストを送信することで本来アクセスできないリソースに対してアクセス可能というSSRFの問題点から、アクセス制御の不備の一種であると判断された結果と考えられます。
また、防止方法として新たに下記が追加されました。

分類	説明	解説
追加	Use well-established toolkits or patterns that provide simple, declarative access controls.	開発者が一からアクセス制御のロジックを実装するのではなく、確立されたツールキットやパターンを使用するよう追加されています。

その他の変更点として、2025年版ではCWEのカテゴリ化について症状（symptom）ではなく根本原因（root cause）に焦点を当てたことから、パストラバーサルに関するCWEを例に挙げると下記の変更がありました。

変更	2021年版	2025年版
無	CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)	CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
無	CWE-23 Relative Path Traversal	CWE-23 Relative Path Traversal
有	CWE-35 Path Traversal: ‘…/…//’	CWE-36 Absolute Path Traversal

2021年版のパストラバーサルに関するCWEの3件のうち、入力値の検証に対する不備であるCWE-35は削除され、根本原因となる絶対パス起因のパストラバーサルであるCWE-36が新たに追加されました。

2. 「A02:2025 - Security Misconfiguration」の順位の大幅な変更

2021年版	2025年版
5位	2位

「A02:2025 - Security Misconfiguration」は、2021年版の5位から2025年版では2位となりました。
本カテゴリが2位となった主な理由として、ソフトウェアエンジニアリングにおいてアプリケーションの挙動が設定に依存している割合が増加し続けていることについて言及しており、テストされたアプリケーションの100%で何らかの設定不備が見つかったことが原因として挙げられています。
セキュリティ設定の不備の定義については、2021年版では記載はありませんでした。一方、2025年版では、システムやアプリケーション、クラウドサービスがセキュリティの観点から不適切に設定されている場合に脆弱性が発生する、と追加されています。

アプリケーションが脆弱性である可能性の説明としては、下記の変更・追加・削除がありました。

分類	説明	解説
変更	A lack of central configuration for intercepting excessive error messages. Error handling reveals stack traces or other overly informative error messages to users.	2021年版から引き続きエラー処理時のスタックトレースやエラーメッセージによる過剰な情報の公開について説明しており、2025年版では新たに過剰なエラーメッセージを防ぐためのアプリケーションの全体的な設定の不足が追加されています。
追加	Excessive prioritization of backward compatibility leading to insecure configuration.	後方互換性を優先することで、安全ではない構成に繋がる点についての説明が追加されています。2025年版内にて言及はされていませんが、本カテゴリのみの影響ではなく、例えばTLSのバージョンや安全でないハッシュ関数を使用することがあれば後述する「A04:2025 Cryptographic Failures」にも影響します。
削除	The software is out of date or vulnerable (see A06:2021-Vulnerable and Outdated Components).	2025年版では、ソフトウェアが古い、または脆弱であることに関する記述が削除されています。しかし、これは本リスクが存在しなくなったわけではなく、2021年版でも「A06:2021 - Vulnerable and Outdated Components」を参照するよう記載されていたことから、2025年版では「A03:2025 - Software Supply Chain Failures」のみの記載になったと考えられます。

防止方法については下記追加がありました。

分類	説明	解説
追加	Proactively add a central configuration to intercept excessive error messages as a backup.	過度なエラーメッセージを漏洩させないためのバックアップ（安全対策）として、アプリケーション全体の設定をするよう追加されています。
追加	If these verifications are not automated, they should be manually verified annually at a minimum.	設定の有効性を確認する検証プロセスについて、2021年版から引き続き自動化された検証プロセスが防止方法として挙げられていますが、自動化された検証プロセスがない場合には、2025年版からは少なくとも年1回手動による検証プロセスを設けるべきであると追加されています。
追加	Use identity federation, short-lived credentials, or role-based access mechanisms provided by the underlying platform instead of embedding static keys or secrets in code, configuration files, or pipelines.	スタティックキーやシークレット（APIキーや長期間の認証情報などを指していると考えられます）をソースコード上や設定ファイル、パイプライン上には埋め込まず、プラットフォームが提供するアイデンティティフェデレーション（SAMLやOIDCなど）や短期間の認証情報、ロールベースのアクセス制御を使用するよう追加されています。

3. 「A03:2025 - Software Supply Chain Failures」と「A10:2025 - Mishandling of Exceptional Conditions」の新規カテゴリが2つ追加

A03:2025 - Software Supply Chain Failures

2021年版	2025年版
6位	3位

コミュニティ調査では、2021年版で2位だった本カテゴリが、2025年版では回答者の50%から1位に選ばれています。また、2021年版の「A06:2021 - Vulnerable and Outdated Components」が大幅に拡張され、ソフトウェア開発におけるサプライチェーン全体を対象とする「A03:2025 - Software Supply Chain Failures」として新たに追加されています。
ここでは、2025年版で対象が大幅に拡大したことにより新たに追加された脆弱性の説明について紹介します。

分類	説明	解説
追加	you do not have a change management process or tracking of changes within your supply chain, including tracking IDEs, IDE extensions and updates, changes to your organization’s code repository, sandboxes, image and library repositories, the way artifacts are created and stored, etc. Every part of your supply chain should be documented, especially changes.	変更管理プロセスの重要性について説明しており、IDEの拡張機能やアップデート、組織のコードリポジトリへの変更、サンドボックス、イメージおよびライブラリリポジトリ、成果物の作成と保存方法などのサプライチェーン内のあらゆる部分の変更を追跡可能なよう文書化されていないことについて追加されています。
追加	you have not hardened every part of your supply chain, with a special focus on access control and the application of least privilege.	アクセス制御と最小権限の適用に特に焦点を当てて、サプライチェーン全体をハードニング（強化）していないことについて追加されています。
追加	your supply chain systems do not have any separation of duty. No single person should be able to write code and promote it all the way to production without oversight from another human being.	一人の人間が別の人間からの監視なしにコードを書いて、本番環境に反映させることが可能であり、サプライチェーン全体に職務分掌の原則がないことについて追加されています。
追加	components from untrusted sources, across any part of the tech stack, are used in or can impact on production environments.	信頼できないソースから取得したコンポーネントが本番環境にて使用されている、または影響を与えている状態にあることについて追加されています。
追加	your CI/CD pipeline has weaker security than the systems it builds and deploys, especially if it is complex.	CI/CDパイプラインが特に複雑な場合には、ビルドおよびデプロイするシステムよりセキュリティ上脆弱であることについて追加されています。

防止方法についても大幅な追加があり、3つの構成に分かれて追加されています。

1. パッチ管理プロセス

2025年版にて新規追加および変更があります。

分類	説明	解説
追加	Centrally generate and manage the Software Bill of Materials (SBOM) of your entire software.	ソフトウェア全体のソフトウェア部品表（SBOM）を一元的に生成・管理するよう追加されています。
追加	Track not just your direct dependencies, but their (transitive) dependencies, and so on.	直接的な依存関係だけではなく間接的な依存関係まで追跡するよう追加されています。
変更	Reduce attack surface by removing unused dependencies, unnecessary features, components, files, and documentation.	2021年版では未使用の依存関係、不要な機能、コンポーネント、ファイルや文書を取り除くよう説明されていましたが、2025年版ではより範囲を広めた文言が追加され、攻撃対象領域を減らすよう追加されています。
変更	Continuously inventory the versions of both client-side and server-side components (e.g., frameworks, libraries) and their dependencies using tools like OWASP Dependency Track, OWASP Dependency Check, retire.js, etc.	2021年版より2つに分割され、2025年版では依存関係の継続的な目録化に使用するツールとして、OWASP Dependency Check、retire.jsのほかOWASP Dependency Trackが追加されています。
変更	Continuously monitor sources like Common Vulnerability and Exposures (CVE), National Vulnerability Database (NVD), and Open Source Vulnerabilities (OSV) for vulnerabilities in the components you use. Use software composition analysis, software supply chain, or security-focused SBOM tools to automate the process. Subscribe to alerts for security vulnerabilities related to components you use.	2021年版より2つに分割されたもう一方となります。2025年版ではコンポーネントの脆弱性の継続的なモニタリングのソースとして、CVEとNVDのほかOpen Source Vulnerabilities (OSV)が追加されています。また、プロセスの自動化としてソフトウェア構成分析ツールのほか、サプライチェーンツールとSBOMツールが追加されています。登録するセキュリティ脆弱性に関するアラートからは電子メールの文言は削除され、単にアラートのみとなりました。
変更	Only obtain components from official (trusted) sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component (see A08:2025-Software and Data Integrity Failures).	2025年版ではコンポーネントを安全なリンクを介して「信頼された」公式のソースからのみ入手するよう強調されており、2021年版から引き続き、改ざんされた悪意のあるコンポーネントの取得を減らすために署名されたパッケージの使用が推奨されています（参照：A08:2025 Software or Data Integrity Failures）。
追加	Deliberately choose which version of a dependency you use and upgrade only when there is need.	使用する依存関係のバージョンを慎重に選択し、必要な場合にのみアップグレードするよう追加されています。
変更	Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider migrating to an alternative. If that is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.	2021年版ではメンテナンスされていない、またはセキュリティパッチが作成されていない古いバージョンのライブラリ・コンポーネントはモニタリングし、パッチ適用できない場合は仮想パッチの展開による対応を求められていましたが、まずは代替手段への移行を検討するよう追加されています。
追加	Update your CI/CD, IDE, and any other developer tooling regularly	CI/CD、IDE、その他の開発ツールを定期的に更新するよう追加されています。
追加	Avoid deploying updates to all systems simultaneously. Use staged rollouts or canary deployments to limit exposure in case a trusted vendor is compromised.	全システムの同時アップデートは避け、信頼できるベンダーが侵害された場合に備えて段階的なロールアウトやカナリアデプロイを使用し、被害を抑えるよう追加されています。

2. 変更管理プロセス

本項目は2025年版にて新規追加となります。下記の変更を追跡するための変更プロセスまたは追跡システムを導入する必要性が挙げられています。

3. ハードニング（強化）対象のシステム

本項目も2025年版にて新規追加となります。下記のシステムにおいて多要素認証の有効化とIAMのロックダウンなどのハードニングの実施が挙げられています。

対象システム	解説
コードリポジトリ	シークレットをコミットしない、ブランチの保護、バックアップの実施
開発者ワークステーション	定期的なパッチ適用、多要素認証、モニタリングなど
ビルドサーバとCI/CD	職務分掌、アクセス制御、署名付きビルド、環境ごとのシークレット管理、改ざん防止ログの導入など
成果物	出所、署名、タイムスタンプによる整合性の確保、環境ごとに再ビルドするのではなく同一の成果物を別環境にプロモートしビルドが不変であることを保証する
Infrastructure as Code	プルリクエストやバージョン管理の運用を含め、コードと同様に管理する

A10:2025 - Mishandling of Exceptional Conditions

2021年版	2025年版
-	10位

2025年版にて新規追加されたカテゴリとなり、具体的なCWEについては記載がなく確認できませんが、2021年版の「Next Steps」である「Code Quality issues」のCWEも含まれています。
本カテゴリでは24のCWEが含まれており、不適切なエラー処理、論理エラー、フェイルオープン、そしてシステムが遭遇する可能性のある異常な状況に起因するその他のシナリオに焦点を当てています。
注目すべきCWEとして具体的に下記が挙げられています。

CWE	日本語訳
CWE-209 Generation of Error Message Containing Sensitive Information	機密情報を含むエラーメッセージの生成
CWE-234 Failure to Handle Missing Parameter	必須パラメータ欠落時の処理失敗
CWE-274 Improper Handling of Insufficient Privileges	不十分な権限の不適切な処理
CWE-476 NULL Pointer Dereference	NULLポインタ参照
CWE-636 Not Failing Securely (‘Failing Open’)	フェイルオープン（安全に失敗しない）

ソフトウェアにおける例外的な状況の不適切な処理は、プログラムが異常かつ予測不可能な状況を防止・検出・対応できない場合に発生し、クラッシュや予期しない動作、そして時には脆弱性に繋がると説明しており、下記3つのいずれか、または複数が関与しているとして挙げられています。

また、例外の不適切な処理が発生する原因として下記が挙げられています。

分類	具体例
入力検証の問題	欠落、不十分、不完全な入力検証
エラー処理箇所	発生した関数ではなく上位階層によるエラー処理遅延
環境状態	メモリ、権限、ネットワークの予期しない状態
例外処理の一貫性	一貫性のない例外処理
例外の未処理	全く処理されない、予測不能な状態に陥る

例外的な状況の不適切な処理は、機密性・可用性・完全性に影響を及ぼす脆弱性を発生させる可能性があるとして下記が挙げられています。

防止方法としては、例外的な情報を適切に処理するために、最悪の事態を想定する必要があること、すべてのシステムエラーを直接「キャッチ」すること、そして問題を解決し確実に回復させるために意味のある対応を実施することが求められています。

下記は防止方法として実施すべき内容の概要となります。

分類	内容
エラー処理	グローバルな例外処理、集約されたエラー処理
トランザクション	Failing Closed（完全なロールバック）
リソース管理	レート制限、リソースクォータ、スロットリング
監視	監視ツール、パターン検出、アラート
開発プロセス	脅威モデリング、設計レビュー、静的解析、性能テスト、ペネトレーションテスト
組織	組織全体で一貫したエラー処理

4. 「A04:2025 - Cryptographic Failures」の暗号について

2021年版	2025年版
2位	4位

「A04:2025 - Cryptographic Failures」は、2021年版で2位だった順位が、2025年版では4位となりました。
新たな説明としては、トランスポート層とアプリケーション層の暗号化について言及されており、トランスポート層は証明書管理の自動化サービスやクラウドベンダーによるサービスによって簡素化されています。一方、アプリケーション層は暗号化対象のデータを判断すること、GDPRやPCI DSSなどへの規制の対象となる場合には追加の対応が必要であることが挙げられています。
ここでは大幅に変更・追加された防止方法について抜粋して紹介します。

分類	説明	解説
追加	Store your most sensitive keys in a hardware or cloud-based HSM.	最も重要な鍵はハードウェアまたはクラウドベースのHSM（Hardware Security Module）に保存するよう追加されています。
変更	Encrypt all data in transit with protocols >= TLS 1.2 only, with forward secrecy (FS) ciphers, drop support for cipher block chaining (CBC) ciphers, support quantum key change algorithms. For HTTPS enforce encryption using HTTP Strict Transport Security (HSTS). Check everything with a tool.	TLS1.1以前やCBCモードには既知の脆弱性が存在するため、2025年版ではTLS1.2以上のみを使用し、CBCモードのサポートを廃止するよう変更されています。また、量子鍵交換アルゴリズムをサポートするよう追加されています。
変更	Disable caching for responses that contain sensitive data. This includes caching in your CDN, web server, and any application caching (eg: Redis).	2021年版でも機密情報を含むキャッシュは無効化するよう説明されていましたが、2025年版からは明示的にキャッシュを無効化する対象として、CDN、Webサーバ、アプリ側のキャッシュ（Redisなど）が追加されています。
追加	Do not use unencrypted protocols such as FTP, and STARTTLS. Avoid using SMTP for transmitting confidential data.	2021年版では、機密データの伝送にFTPとSMTPを使用しないよう説明されていましたが、2025年版では新たにSTARTTLSを使用しないよう追加されています。
変更	Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, yescrypt, scrypt or PBKDF2-HMAC-SHA-512. For legacy systems using bcrypt, get more advice at OWASP Cheat Sheet: Password Storage	2025年版からはパスワードの安全な保存に使用されるハッシュ関数としてyescryptが追加され、bcryptは除外されました。bcryptはレガシーシステムでの使用に限定され、使用する場合にはOWASP Cheat Sheet: Password Storageを参照するよう追加されています。
変更	You need to prepare now for post quantum cryptography (PQC), see reference (ENISA) so that high risk systems are safe no later than the end of 2030.	耐量子計算機暗号（PQC：Post-Quantum Cryptography）は、量子コンピュータの計算能力を用いても解読することが極めて困難な暗号技術のことです。 2030年末までに高リスクのシステムの安全性を確保するため、今から耐量子計算機暗号への移行準備の必要性について言及されており、ENISAのA Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptographyを参照すると、暗号化データを収集しておき、量子コンピュータの実用化後に復号することを目的とするSNDL（Store Now, Decrypt Later）攻撃について言及されています。現時点ではリスクは顕在化していないものの、将来的なリスクを考慮して追加された内容と考えられます。

5. AI関連への言及

2025年版では新たにAI・LLMについてのリスク・活用についての言及がいくつかのカテゴリにて追加されました。

カテゴリ	AI関連の内容
A05:2025 - Injection	LLMに対するプロンプトインジェクション（LLM01:2025 Prompt Injectionを参照）
A09:2025 - Security Logging & Alerting Failures	AI支援によるアラートの誤検知低下
X03:2025 Inappropriate Trust in AI Generated Code (‘Vibe Coding’)	AIが生成したコードの使用によるリスク

特に、トップ10には入らなかったものの「Next Steps」の「X03:2025 Inappropriate Trust in AI Generated Code (‘Vibe Coding’)」では、1カテゴリとして大きく取り上げられています。
新たに追加された背景として、AIの生成したコードについては人間が書いたコードよりも多くの脆弱性を含むことが知られ、文書化されていることが挙げられています。

カテゴリ自体が新規追加のため、ここではAIの使用に対する防止方法について概要を紹介します。

分類	項目	詳細
責任とレビュー	コードへの責任	AI生成・オンライン上からコピーしたコードに対して完全な理解と責任を持つ
	徹底的なレビュー	AIの支援を受けたコードは、人間の目とセキュリティツール（SASTなど）を使用して脆弱性がないか徹底的にレビューする
	反復的な改善プロセス	自身でコードを書く→AIに改善提案させる→人間がコードをチェックする→結果に満足するまでAIにて修正する
	バイブコーディングの回避	複雑な機能、ビジネス上重要なプログラム、長期間使用されるプログラムへのバイブコーディングの使用は非推奨
技術的対策	RAGへのポリシー強制	組織のセキュリティガイドライン、標準、ポリシーなど安全なコードサンプルをRAGサーバで使用しポリシーや標準を適用する
	ガードレールの導入	AI使用におけるプライバシーとセキュリティのためのガードレールを導入する
	MCPサーバの導入	IDEとAIの間にModel Context Protocol (MCP) サーバを導入し、選択したセキュリティツールの使用を強制する
	シャドーAI対策	許可されていないAIツール（シャドーAI）に対して技術的なチェックとセーフガードを実装する
契約・インフラ	プライベートAIの利用	組織のデータ、クエリ、コード、その他の機密情報をAIモデルに学習させない契約（プライバシー契約を含む）が締結可能なプライベートAIを購入することが理想
プロセス・教育	SDLCへのポリシー統合	組織内（開発者および全ての従業員）でAIをどのように使用すべきか周知するためのポリシーとプロセスをSDLC（Software Development Life Cycle）の一部として実装する
	安全なプロンプトの作成	ITセキュリティと社内セキュアコーディングガイドラインを考慮した高品質かつ効果的なプロンプト集を作成する
	教育と訓練	開発者へ安全なAI利用方法と開発におけるAIのベストプラクティスについて教育

2025年版では紹介はされていませんが、上記対応の参考としてAIセキュリティとプライバシーのガイダンスを提供するOWASP AI Exchangeがあります。

まとめ

本記事では、「OWASP Top 10 2025」で大きな変更のある内容を5つに分けて抜粋し紹介しました。
OWASP Top 10は意識向上を目的としてまとめられた文書であり、Webアプリケーションにおけるセキュリティの最低限の基準となりますが、広範囲にわたるWebアプリケーションのリスクについて、対応の必要性を認識することができます。
今回の変更に見られるように、推奨される対策や禁止事項は変化していくため、従来から存在するリスクへの継続的な対応が求められます。加えて、AIや量子コンピュータといった新たな技術の普及に伴うセキュリティ対策についても検討していく必要があります。
今後も変化し続けるリスクに適切に対応していくためには、継続的なセキュリティ対策への取り組みが重要です。
NTTデータ先端技術では、Webアプリケーションのセキュリティ対策に向けて各種サービスを提供しておりますので、お気軽にお問い合わせください。
セキュリティ診断サービスマップ

参考