OWASP Top 10とは？2025年版の10大リスクと企業のセキュア開発への活用方法|セキュリティ対策Lab

投稿日時: 2026年09月28日更新日時: 2026年09月28日

OWASP Top 10は、Webアプリケーションで優先して理解したいセキュリティリスクを整理した、OWASP Foundationの啓発資料です。2026年9月時点の最新版は「OWASP Top 10:2025」で、アクセス制御、設定不備、ソフトウェアサプライチェーン、暗号、インジェクション、認証、ログなど10カテゴリで構成されています。

2025年版では、2021年版の「脆弱で古くなったコンポーネント」が「ソフトウェアサプライチェーンの不備」へ拡張され、エラー処理やフェイルオープンなどを扱う「例外的な状況への不適切な対応」が新設されました。Server-Side Request Forgery（SSRF）は独立カテゴリから「アクセス制御の不備」へ統合されています。

従業員600人以上の企業では、自社開発だけでなく、SaaS、委託開発、OSS、GitHub Actions、npmなどの依存関係まで含めて管理する必要があります。OWASP Top 10は開発者教育の入口として使えますが、これだけを満たせば安全というチェックリストではありません。開発要件や受入試験ではOWASP ASVS、開発プロセス全体ではNIST SSDFなどと組み合わせる方が実務に落とし込みやすくなります。

OWASP Top 10とは

OWASP（Open Worldwide Application Security Project）は、アプリケーションセキュリティに関するオープンなプロジェクトやガイドラインを提供する非営利組織です。

OWASP Top 10は、開発者やWebアプリケーションセキュリティ担当者向けに、主要なセキュリティリスクを10カテゴリへ整理した資料です。OWASP自身は「standard awareness document」と位置付けており、認証制度や法令上の基準ではありません。

最新版の2025年版は第8版です。OWASPは、2021年以降にテストされたアプリケーションのデータとコミュニティ調査を用いてカテゴリを見直しています。

2025年版のデータ集計では、同じアプリケーション内で同一の弱点が何件見つかったかではなく、そのアプリケーションに対象CWEが1つ以上存在したかを重視しています。また、テストデータだけでは把握しにくいリスクを補うため、コミュニティ調査も組み合わせています。

そのため、OWASP Top 10の順位を「実際の攻撃件数が多い順」と解釈するのは適切ではありません。Webアプリケーションで優先して理解すべきリスク群として読みます。

OWASP Top 10 2025年版の一覧

順位	カテゴリ	概要	企業で確認したい点
A01	アクセス制御の不備	本来許可されていないデータや機能へアクセスできる	認可処理、権限分離、IDOR、管理機能へのアクセス
A02	セキュリティ設定の不備	初期設定、公開範囲、不要機能、権限などの設定ミス	クラウド・Web・フレームワーク・SaaSの設定レビュー
A03	ソフトウェアサプライチェーンの不備	依存関係、ビルド、配布基盤、外部コンポーネントの侵害	OSS、CI/CD、パッケージ、SBOM、依存関係の更新
A04	暗号化の不備	暗号化や鍵管理の不足・誤用	TLS、保存データ暗号化、鍵・証明書・シークレット管理
A05	インジェクション	入力値が命令として解釈される	SQL、OSコマンド、LDAP等への入力処理
A06	安全性を欠いた設計	必要なセキュリティ制御が設計段階で考慮されていない	脅威モデリング、業務ロジック、悪用ケース
A07	認証の不備	本人確認やセッション管理に問題がある	MFA、セッション、パスワード、認証フロー
A08	ソフトウェアまたはデータの完全性の不備	コードやデータの信頼性・完全性を検証していない	署名、CI/CD、更新ファイル、シリアライズ等
A09	セキュリティログとアラートの不備	攻撃を記録・通知・対応できない	認証、権限変更、異常操作、管理操作のログと通知
A10	例外的な状況への不適切な対応	エラー時に安全側へ倒れず、情報露出や制御回避につながる	エラー処理、フェイルクローズ、異常系テスト

10項目をすべて同じ方法で検査できるわけではありません。A05のインジェクションはSASTやDAST、コードレビューなどで確認しやすい一方、A06の安全性を欠いた設計は、設計レビューや脅威モデリングが必要です。A09も、ログが存在するだけでなく、実際に異常を検知して担当者へ通知されるかまで確認する必要があります。

2021年版から2025年版で何が変わったか

OWASPは2025年版について、「2つの新カテゴリと1つの統合」があると説明しています。

2025年版	2021年版からの主な変更
A01 アクセス制御の不備	1位を維持。2021年のA10「SSRF」を統合
A02 セキュリティ設定の不備	2021年の5位から2位へ
A03 ソフトウェアサプライチェーンの不備	「脆弱で古くなったコンポーネント」を、依存関係・ビルド・配布基盤まで含む範囲へ拡張
A04 暗号化の不備	2021年の2位から4位へ
A05 インジェクション	2021年の3位から5位へ
A06 安全性を欠いた設計	2021年の4位から6位へ
A07 認証の不備	名称を簡略化し7位を維持
A08 ソフトウェアまたはデータの完全性の不備	8位を維持
A09 セキュリティログとアラートの不備	「監視」から「アラート」へ名称を変更
A10 例外的な状況への不適切な対応	2025年版で新設

2025年版で企業側への影響が大きいのは、A03の範囲拡大です。

2021年版では、既知の脆弱性を含むライブラリや古いコンポーネントの利用が中心でした。2025年版では、依存ライブラリだけでなく、ビルドシステム、CI/CD、パッケージ配布、更新経路を含むソフトウェアサプライチェーン全体が対象になりました。

OWASPはA03について、コミュニティ調査で回答者の50%が1位に選んだと説明しています。一方で、テストが難しく、収集データだけでは十分に表れにくい領域ともしています。

A01・A02：アクセス制御と設定不備は実際の情報漏洩につながる

セキュリティ対策Labで2026年9月に取り上げた生命保険協会の個人情報閲覧事案では、ログインしていないゲストユーザーに、他の利用者の個人情報を参照できる権限が誤って付与されていました。

閲覧可能だった個人情報は延べ37,929件、重複を除くと27,407件でした。設定不備は2021年7月のシステム運用開始から2026年7月まで継続していました。

この事案は、外部から認証情報を盗まれて侵入されたケースではありません。正規のシステム設定の中で、本来与えるべきではない参照権限が付与されていました。

OWASP Top 10の観点では、アクセス制御を「ログインできるかどうか」だけで確認しないことが分かります。

確認対象には、未認証ユーザーが参照できるデータ、一般ユーザーと管理者の権限差、他ユーザーIDを指定した場合の応答、APIごとの認可処理、新機能追加後の権限設定、本番リリース後の定期的な権限レビューなどが含まれます。

A03：ソフトウェアサプライチェーンは「脆弱なライブラリ」だけではない

A03「ソフトウェアサプライチェーンの不備」は、2025年版の変更点を象徴するカテゴリです。

現在のWebアプリケーションは、自社コードだけでは構成されていません。OSSライブラリ、npmやPyPI等のパッケージ、GitHub Actions、コンテナイメージ、CI/CDサービス、外部API、SaaS、ビルドツールなども開発・配布経路を構成します。

セキュリティ対策Labで扱ったtj-actions/changed-filesのサプライチェーン攻撃では、GitHub Actionsで広く利用されていたアクションが改ざんされ、ワークフロー内のシークレットがビルドログへ出力される状態になりました。

この種の事案では、SCAで既知CVEを持つライブラリを探すだけでは管理しきれません。

企業側では、利用OSSとバージョン、推移的依存関係、CI/CDで使うシークレットの権限、パッケージの配布元、ビルド環境から本番環境への権限、SBOMを脆弱性管理へ接続できているかを確認します。

英国NCSCのSoftware Security Code of Practiceも、開発ライフサイクル全体で第三者コンポーネントを把握し、依存関係のリスクを評価するよう案内しています。

1つのインシデントを1カテゴリへ無理に当てはめない

2026年8月に株式会社イノベーションが公表したGitHub不正アクセスでは、62,691名分の個人情報漏洩が確認されました。

同社の確定報によると、原因は2点でした。1つ目はGitHubへアクセスするための認証情報がプログラムの設定ファイルへ直接記載され、その認証情報を第三者が取得・悪用したことです。2つ目は、本来データベース等で管理すべき個人情報の一部がGitHubリポジトリにも保存されていたことです。

セキュリティ対策Labでは、「認証情報のハードコーディング」と「個人情報のリポジトリ保存」という独立した2つの問題として整理しています。

この事例をOWASP Top 10へ当てはめる際に、1つのカテゴリへ無理に分類する必要はありません。認証、秘密情報管理、データ保管、アクセス権、ログ監視、開発プロセスなど、複数の管理策が関係します。

OWASP Top 10は「原因を1つ選ぶための分類表」ではなく、開発・運用のどこに確認漏れがあるかを洗い出すために使う方が実務的です。

OWASP Top 10を開発ライフサイクルへどう組み込むか

開発工程	主に確認したいOWASPカテゴリ	実務での確認例
要件定義	A01、A04、A06、A07	データ分類、権限、認証、暗号、悪用ケースを要件化
設計	A01、A06、A07、A10	脅威モデリング、認可モデル、異常系・フェイルクローズ設計
実装	A04、A05、A07、A10	入力処理、暗号API、セッション、エラー処理
CI/CD	A03、A08	依存関係、署名、ビルド権限、シークレット管理
テスト	A01、A02、A05、A07、A10	権限テスト、設定確認、異常入力、認証・セッション
リリース	A02、A03、A08	本番設定、不要機能、依存関係、成果物の完全性
運用	A02、A03、A09	設定変更、脆弱性管理、ログ、アラート、インシデント対応

NISTのSecure Software Development Framework（SSDF）は、セキュリティを特定のテスト工程だけに置かず、組織準備、ソフトウェア保護、安全なソフトウェアの生成、脆弱性対応といった開発ライフサイクル全体へ組み込む考え方を示しています。

OWASP Top 10を「何を確認するか」、SSDFを「開発組織としてどう継続運用するか」の整理に使うと、役割を分けやすくなります。

OWASP Top 10だけをセキュリティ基準にしない

OWASP自身も、Top 10を主に啓発資料と位置付けています。

2025年版では、Top 10をコーディング標準、コードレビュー、ペネトレーションテストなどに使う場合、「最低限の出発点」であると説明しています。

理由は、10カテゴリの一部が自動テストだけでは評価できないためです。

A06「安全性を欠いた設計」は、コードに明確な脆弱性がなくても、設計上必要な制御自体が存在しなければ成立します。A09「セキュリティログとアラートの不備」も、ログ出力処理がコードに存在するかだけでは評価できません。本番環境で必要なイベントが記録され、異常時に通知され、SOCやCSIRTが対応できるかまで確認する必要があります。

開発・テスト要件として具体的な検証項目が必要な場合、OWASPはASVS（Application Security Verification Standard）の利用を推奨しています。

したがって、調達仕様書や委託開発契約へ「OWASP Top 10に対応すること」とだけ記載するより、必要なASVSレベルや個別の検証要件、成果物、診断範囲を定義する方が、受入時に確認しやすくなります。

米国・英国・イスラエルの資料と組み合わせる

米国NISTのSSDFは、安全なソフトウェア開発の実務をSDLCへ組み込むための共通フレームワークです。ソフトウェア開発企業だけでなく、ソフトウェアを調達する企業が、供給者との要求事項を整理する用途も想定されています。

CISAとFBIのSecure by Design関連ガイダンスでは、ソフトウェアメーカー側が顧客へ負担を転嫁せず、開発段階から安全性を組み込む考え方を示しています。2025年に更新された「Product Security Bad Practices」でも、製品開発全体でセキュリティを優先するようソフトウェアメーカーへ案内しています。

英国NCSCのSoftware Security Code of Practiceでは、Secure Design and Developmentの中で、第三者コンポーネントを含むソフトウェア構成を把握し、ライフサイクルを通じて依存関係のリスクを評価することを示しています。OWASP 2025のA03と組み合わせると、単なるCVE対応からサプライチェーン全体の管理へ対象を広げられます。

イスラエル国家サイバー局（INCD）は、公式教育プログラム「WebSec」で、現在利用されているWeb攻撃、攻撃で悪用される脆弱性、被害、防御方法を実践的に扱っています。INCDは民間を含むイスラエルのサイバー防御を担い、組織向けのサイバー防御方法論や教育資源も公開しています。