Webアプリケーションの開発や運用に携わっていると、取引先の調達要件や社内のセキュリティ基準、脆弱性診断の見積もりなどで「OWASP Top 10に沿って対策してほしい」と求められる場面が増えています。その基準となるOWASP Top 10は、2025年に最新版の「OWASP Top 10:2025」が公開されました。
2021年版をすでに知っている方がまず確認したいのは、2025年版で何がどう変わったのか、という点ではないでしょうか。検索すると2017年版・2021年版・2025年版の解説が入り混じっており、「今の最新はどの10項目で、前の版から何が入れ替わったのか」が分かりにくい状態になっています。
本記事では、2025年版の全10項目（A01〜A10）を公式の正式名称・公式日本語名とともに一覧で示し、2021年版からの変更点を対応表で整理します。そのうえで各項目の典型例と対策、新設された2つのカテゴリの背景、AI生成コードへの過信などの新しい論点、そして自社のWebアプリケーションをOWASP Top 10基準で点検する進め方までを解説します。
目次
一括ダウンロードする
【2025年版】OWASP Top 10の全10項目一覧（A01〜A10）
はじめに、2025年版の全10項目を順位順に示します。名称はOWASP公式サイトの正式名称（英語）と、公式日本語版に掲載されている日本語名を併記しました。OWASP Top 10は数値の大きさではなく、A01が最も重大とされる順位です。
| コード | 正式名称（英語） | 公式日本語名 |
|---|---|---|
| A01:2025 | Broken Access Control | アクセス制御の不備 |
| A02:2025 | Security Misconfiguration | セキュリティ設定の不備 |
| A03:2025 | Software Supply Chain Failures | ソフトウェアサプライチェーンの不備 |
| A04:2025 | Cryptographic Failures | 暗号化の不備 |
| A05:2025 | Injection | インジェクション |
| A06:2025 | Insecure Design | 安全性を欠いた設計 |
| A07:2025 | Authentication Failures | 認証の不備 |
| A08:2025 | Software or Data Integrity Failures | ソフトウェアまたはデータの完全性の不備 |
| A09:2025 | Security Logging and Alerting Failures | セキュリティログとアラートの不備 |
| A10:2025 | Mishandling of Exceptional Conditions | 例外的な状況への不適切な対応 |
「OWASP Top 10:2025」は、OWASP公式が現在公開している最新版です。
2021年版から2025年版への変更点
ここからは、2021年版を知っている方向けに、2025年版で何が変わったのかを整理します。OWASPは変更の全体像を、新設された2カテゴリと1つの統合として説明しています。
2025年版では、2つのカテゴリが新設され、1つが統合されました。
出典：はじめに（Introduction）｜OWASP Top 10:2025
2021年版と2025年版を並べると、変更は次の対応表のように整理できます。新しく加わった項目、ほかのカテゴリに統合されて単独では姿を消した項目、順位が動いた項目、名称が変わった項目を1枚で確認できます。
| 2021年版 | 2025年版での扱い |
|---|---|
| A01 Broken Access Control | A01 のまま首位を維持。2021年版のA10（SSRF）がこのカテゴリに統合された |
| A02 Cryptographic Failures | A04 へ（2ランク下降） |
| A03 Injection | A05 へ（2ランク下降） |
| A04 Insecure Design | A06 へ（2ランク下降） |
| A05 Security Misconfiguration | A02 へ（3ランク上昇） |
| A06 Vulnerable and Outdated Components | A03「ソフトウェアサプライチェーンの不備」へ発展・拡張（単独カテゴリとしては姿を消す） |
| A07 Identification and Authentication Failures | A07 のまま。名称が「認証の不備（Authentication Failures）」へ変更 |
| A08 Software and Data Integrity Failures | A08 のまま。英語名が「and」から「or」へ微修正 |
| A09 Security Logging and Monitoring Failures | A09 のまま。名称が「セキュリティログとアラートの不備（Monitoring→Alerting）」へ変更 |
| A10 Server-Side Request Forgery (SSRF) | 単独カテゴリを廃止し、A01 に統合 |
| （該当なし） | A10「例外的な状況への不適切な対応」を新設 |
出典・参考資料（2件）
この対応表を変更の種類ごとに整理すると、新設・統合・順位変動・改称の4つにまとまります。
新設された2つのカテゴリ
2025年版で新しく独立したカテゴリは、A03とA10の2つです。いずれも近年の開発現場でリスクが広がっている領域で、自社の対策リストに項目として加える必要があります。
A03 ソフトウェアサプライチェーンの不備
A03は、2021年版のA06「脆弱で古いコンポーネント（Vulnerable and Outdated Components）」を発展・拡張したカテゴリです。
OWASPは、依存ライブラリやビルドシステム、配布インフラまでを含むソフトウェア供給網全体で起こる危害へと対象を広げたと説明しています。既知の脆弱性を持つ部品を使うことだけでなく、開発から配布に至る過程に入り込むリスク全般を扱う点が、旧カテゴリとの違いです。
このカテゴリは、OWASPがコミュニティに対して実施した調査で、回答者の50%が最も重大なリスクに選んだと記録されています。もともと2013年版に「既知の脆弱性を持つコンポーネントの使用」として登場した論点が、サプライチェーン全体のリスクへと範囲を広げてきた経緯も公式に説明されています。
A10 例外的な状況への不適切な対応
A10は、2025年版で完全に新しく加わったカテゴリです。エラー処理の不備や論理エラー、異常時に安全側ではなく危険側に倒れてしまう動作（failing open）など、システムが想定外の状況に直面したときに生じる問題を扱います。OWASPは、このカテゴリに24件のCWE（共通脆弱性タイプの識別子）が含まれると説明しています。
出典・参考資料（1件）
SSRF・「機微な情報の露出」はどこへ行ったのか
2021年版を見ていた方が戸惑いやすいのが、単独では見当たらなくなった項目の行き先です。2021年版でA10だったSSRF（サーバーサイドリクエストフォージェリ）は、2025年版では単独カテゴリを廃止し、首位のA01「アクセス制御の不備」に統合されました。A01のカテゴリページでも、SSRFに対応するCWE-918が収録対象として明記されています。
これは2025年版そのものの変更ではありませんが、2021年版より前を知る方が混同しやすいのが「機微な情報の露出（Sensitive Data Exposure）」です。これは2021年版の時点ですでに単独カテゴリから外れ、原因側である暗号化の問題（2025年版ではA04「暗号化の不備」）として整理されています。
2025年版でも同じ考え方が引き継がれており、症状ではなく原因で分類する方針が貫かれています。
出典・参考資料（1件）
順位が大きく動いた項目
順位の変動で最も目立つのは、A02「セキュリティ設定の不備」です。2021年版の5位から2025年版では2位へと3ランク上昇しました。クラウドやコンテナの設定ミスが現実の被害に直結している状況を反映した動きといえます。
一方で、2021年版で上位だった暗号化の不備（2位→4位）、インジェクション（3位→5位）、安全性を欠いた設計（4位→6位）は、それぞれ2ランクずつ順位を下げています。首位のアクセス制御の不備は、2025年版でも1位を維持しました。
出典・参考資料（1件）
名称が変わった項目
順位や位置づけは変わらないものの、名称が変わった項目があります。日本語名が変わったのはA07とA09の2項目です。A07は「Identification and Authentication Failures（識別と認証の不備）」から「Authentication Failures（認証の不備）」へ、冒頭の「識別」が外れました。
A09は「Security Logging and Monitoring Failures」から「Security Logging and Alerting Failures」へ、「Monitoring（監視）」が「Alerting（アラート）」へと変わっています。
記録を取るだけでなく、異常を検知して通知するところまでを含意する表現に寄せた変更です。このほかA08は、日本語名は変わらず英語名のみ「Software and Data Integrity Failures」から「Software or Data Integrity Failures」へ、「and」が「or」へ微修正されています。
出典・参考資料（1件）
そもそもOWASP Top 10とは（2025年版の位置づけ）
ここで、OWASP Top 10そのものの位置づけを簡単に整理します。すでにご存じの方は各項目の典型例と対策へ進んでください。
OWASP（Open Worldwide Application Security Project）は、Webアプリケーションのセキュリティ向上を目的に、ガイドラインや検証標準などを無償で公開している非営利の国際コミュニティです。
その代表的な成果物のひとつが、Webアプリケーションにとって重大なセキュリティリスクをまとめた「OWASP Top 10」で、数年ごとに改訂されています。プロジェクトはBrian Glas、Neil Smithline、Tanya Janca、Torsten Gigler、Andrew van der Stockの各氏がリーダーを務めています。
OWASP Top 10は、重大なリスクを広く周知するための啓発文書と位置づけられており、これを満たせば安全が保証される網羅的なチェックリストではありません。自社のWebアプリケーションが各項目に対応できているかを確認する出発点として使い、実際の検査は後述する自己点検ツールや脆弱性診断サービスと組み合わせるのが実務的な進め方です。
出典・参考資料（1件）
全10項目の典型例と2025年の今やるべき対策（A01〜A10）
ここからは、各項目が具体的にどのような問題で、自社で何を確認・対策すべきかを順に整理します。各項目の攻撃手口や対策をさらに詳しく確認したい場合は、OWASP Top 10そのものを項目ごとに掘り下げた解説記事もあわせてご覧ください。ここでは、2025年版を自社の点検に落とし込むための要点に絞って解説します。
A01 アクセス制御の不備：本来アクセスできないはずのデータや操作に、権限のない利用者が到達できてしまう問題です。URLのIDを書き換えて他人のデータを閲覧できる、管理者機能に一般利用者が入れる、といった例が典型です。
対策は、サーバー側の信頼できるコードで利用者ごとの権限を必ず検証し、公開リソース以外は初期状態を「原則拒否」にすることです。検証をフロントエンドやクライアント側のコードに頼ると回避されます。
アクセス制御の仕組みは一か所に実装して全体で使い回し、権限は各レコードの所有者に結びつけて、任意のIDを指定して他人のデータを操作できないようにします。
あわせて、ディレクトリの一覧表示を無効化し、「.git」やバックアップファイルを公開領域に置かないようにします。アクセス制御の失敗はログに記録し、繰り返し起きた際は管理者へ通知します。APIやコントローラにはレート制限をかけ、ログアウト時はサーバー側のセッションを無効化してJWTは短命にします。
SSRFがこのカテゴリに含まれるため、サーバーが外部へ送るリクエストの宛先制限もあわせて確認します。
A02 セキュリティ設定の不備：ソフトウェアやクラウドの設定が安全でない状態を指します。初期パスワードの放置、不要な機能やポートの開放、クラウドストレージの公開設定ミスなどが該当します。
対策は、堅牢化した環境を素早く再現できる手順を用意し、開発・検証・本番の各環境を同じ構成にそろえる（認証情報だけ環境ごとに分ける）ことです。
不要な機能・フレームワーク・サンプルは導入せず、スタックトレースなどの詳細なエラーをそのまま利用者へ返さないよう、エラー処理を一元化します。鍵やシークレットはコードや設定ファイルに直接埋め込まず、短命の認証情報や基盤側のロールで扱います。
設定が意図どおりかは自動で継続的に点検し（自動化できない場合も最低年1回は手動で確認）、クラウドストレージの公開範囲もパッチ管理の一環として見直します。
A03 ソフトウェアサプライチェーンの不備：利用している外部ライブラリやビルド・配布の仕組みに起因するリスクです。既知の脆弱性を持つ部品の利用に加え、改ざんされた部品の混入までを含みます。
対策は、直接の依存だけでなく間接的な依存（推移的依存）まで含めてソフトウェア部品表（SBOM）を一元的に整備することです。そのうえで、CVE（公開された脆弱性の識別子）やNVD（米国の脆弱性データベース）などの脆弱性情報を、ソフトウェア構成分析（SCA）ツールで継続的に監視します。
部品は公式の信頼できる配布元から安全な経路で入手し、できるだけ署名付きのものを選んで改ざんを検知します。使っていない依存は削除し、更新は必要なときに版を見極めて行います。
ビルドパイプライン側も、CI/CDやIDEを最新に保ち、権限の分離・ビルドへの署名・環境ごとに閉じたシークレット管理で固めます。配布時は全システムの一斉更新を避け、段階的な展開（カナリアリリース）で影響範囲を絞ります。
A04 暗号化の不備：通信や保管データの暗号化が不十分、または古い方式を使っている問題です。平文での保存・送信、弱いアルゴリズムの利用、鍵管理の不備などが含まれます。
対策は、まず扱うデータを分類し、不要な機微情報は保持しない（保持しなければ盗まれない）ことです。通信はTLS1.2以上で暗号化してHTTPSを強制し、保管データは分類に応じて暗号化します。
MD5やSHA-1、CBCモードなど古くなった方式は使わず、できるだけ認証付き暗号を用います。パスワードは、Argon2・scrypt・PBKDF2など、ソルトとコスト（計算の重さ）を設定した方式で保存します。鍵は安全に生成・保管し、定期的に更新します。
A05 インジェクション：利用者が入力した値が、命令の一部としてそのまま解釈されてしまう問題です。SQLインジェクションやクロスサイトスクリプティング（XSS）が代表例で、ほかにもNoSQL・OSコマンド・LDAPへのインジェクションが含まれます。
最も確実な対策は、インタープリタを介さない安全なAPIやパラメータ化された問い合わせ（ORMを含む）を使い、データと命令を分離することです。あわせてサーバー側で入力値を許可リスト方式で検証し、動的な問い合わせがどうしても残る場合はインタープリタごとのエスケープを施します。
ただしテーブル名や列名はエスケープできないため、利用者の入力をそれらに使わないようにし、XSS対策として出力時には表示される文脈に応じたエスケープを行います。
A06 安全性を欠いた設計：実装レベルのバグではなく、設計段階でリスクを織り込めていないことによる問題です。対策は、開発の早い段階で想定される脅威を洗い出す脅威モデリングを行い、安全な設計パターンを前提に機能を組み立てることです。コードの修正だけでは対応できないため、設計レビューの工程が重要になります。
A07 認証の不備：ログインや本人確認の仕組みが弱く、なりすましを許してしまう問題です。総当たり攻撃への耐性不足、使い回しパスワードの許容、多要素認証の未導入などが含まれます。
対策は、多要素認証を導入し、初期パスワードをそのまま運用しないことです。新規・変更時のパスワードは、流出済み・脆弱なパスワードの一覧と突き合わせて弾き、定期的な強制変更は課さずNIST SP 800-63Bなどの基準に沿わせます。
ログインの失敗には回数制限や遅延を入れて記録・通知し、ログイン後は新しいセッションIDを発行して、ログアウト時や一定時間の経過でセッションを無効化します。認証やセッション管理は自作せず、実績のある仕組みを使うのが安全です。
A08 ソフトウェアまたはデータの完全性の不備：更新プログラムやデータが、改ざんされていないことを検証できていない問題です。検証なしの自動更新や、信頼できない配信経路の利用などが該当します。更新・配布物には署名を付けて検証し、改ざんを検知できる仕組みを組み込みます。
A09 セキュリティログとアラートの不備：攻撃や異常の記録が不十分で、検知や事後対応ができない問題です。記録を取るだけでなく、異常を検知して通知するところまでが求められます。対策は、重要な操作やエラーを記録し、不審な挙動を検知して担当者へ通知する体制を整えることです。
A10 例外的な状況への不適切な対応：2025年版の新設カテゴリで、エラー処理や異常時の挙動の不備を扱います。例外が起きたときに安全側ではなく危険側に倒れてしまう動作や、想定外の入力で処理が破綻する状態が該当します。異常時の挙動を設計段階で定義し、エラー時は安全側に倒れる（fail safe）ように実装したうえで、例外処理も検査対象に含めます。
これらは出発点であり、自社のアプリケーションが実際に各項目へ対応できているかは、後述の自己点検や脆弱性診断で確認する必要があります。
出典・参考資料（7件）
- 参考資料：OWASP Top 10:2025（日本語）｜OWASP Foundation
- 出典：A01:2025 Broken Access Control（How to Prevent）｜OWASP Top 10:2025
- 出典：A02:2025 Security Misconfiguration（How to Prevent）｜OWASP Top 10:2025
- 出典：A03:2025 Software Supply Chain Failures（How to Prevent）｜OWASP Top 10:2025
- 出典：A04:2025 Cryptographic Failures（How to Prevent）｜OWASP Top 10:2025
- 出典：A05:2025 Injection（How to Prevent）｜OWASP Top 10:2025
- 出典：A07:2025 Authentication Failures（How to Prevent）｜OWASP Top 10:2025
一括ダウンロードする
OWASP Top 10:2025はどう作られたか（CWE・データの要点）
順位や項目の信頼性を判断するうえで、このリストがどのように作られているかを知っておくと役立ちます。記事によってCWEの件数などの数値が食い違って見えることがありますが、これは異なる数値を混同していることが原因です。OWASP公式の数値で整理します。
OWASPは、まず実データにもとづいてカテゴリを順位付けし、そのうえでコミュニティ調査の回答で選ばれた2カテゴリを加える形で、最終的な10カテゴリを選定しています。分析対象としたCWEは、2017年版の約30件、2021年版の約400件から、2025年版では589件へと増えています。
このうち、実際にTop 10の10カテゴリに割り当てられているCWEは248件です。MITREが配布するCWE辞書全体には968件が収録されており、これら3つの数字は意味が異なります。
1カテゴリあたりのCWEは平均25件です。最も少ないのがA03（ソフトウェアサプライチェーンの不備）とA09（セキュリティログとアラートの不備）の各5件、最も多いのがA01（アクセス制御の不備）の40件で、OWASPは1カテゴリあたりを40件で頭打ちにしています。分類は、可能な限り症状ではなく根本原因に着目する方針が示されています。
出典・参考資料（1件）
次点カテゴリと今後の動向（AI生成コードへの過信＝Vibe Coding）
OWASP Top 10は仕組み上、最も重大な10件に絞られます。そのため、収録を検討されながら今回は入らなかった「次点」のリスクが別途公開されています。
2025年版の次点は、X01 アプリケーションの回復力の欠如（Lack of Application Resilience）、X02 メモリ管理の不備（Memory Management Failures）、X03 AI生成コードへの過信（Inappropriate Trust in AI Generated Code、通称 Vibe Coding）の3つです。
X01は、2021年版の「サービス拒否（Denial of Service）」を改称したものである点も公式に説明されています。
このうち、決済・金融領域の開発現場にとって見逃せないのがX03です。OWASPは、AIの支援で書かれたコードにとどまらず、人のレビューをほとんど経ずにコードを書いて反映する開発（いわゆるVibe Coding）が広がっていると指摘し、次のように述べています。
Although there are currently no CVEs or CWEs related to AI generated code, it is well known and documented that AI generated code often contains more vulnerabilities than code written by human beings.
出典：Next Steps（X03 Inappropriate Trust in AI Generated Code）｜OWASP Top 10:2025
X03は現時点で紐づくCVE（公開された脆弱性の識別子）やCWEが無く（公式ページの対応CWEは「-none-」）、データにもとづく項目ではなく、今後に向けた注意喚起としての位置づけです。本体のTop 10とは区別して捉える必要があります。
OWASPは対策として、コミットするコードには自分が責任を負うこと、AIが補助したコードは自分の目と静的解析などのセキュリティツールの双方で十分にレビューすることを挙げています。さらに、複雑な機能や事業の根幹を担うプログラム、長期間使うプログラムには、Vibe Codingを推奨しないとしています。
AIで開発速度を上げている組織ほど、生成されたコードを前提なしに信頼しない運用ルールが重要になります。
出典・参考資料（1件）
この「AIが生成したコードを無条件には信頼しない」という考え方について、MCB FinTechカタログの独自インタビューでは、脆弱性診断の現場からも次のような見解が示されました。
AIコーディングが当たり前になるほど、「AIが書いたコードも含めて、日常的に検証できる仕組み」が重要になります。その文脈で、AIエージェントがハッカーをエミュレーションして侵入テストを行い、ログや証跡を残す“AIペンテスト”の方向性も出てきています。これが進むと、コストや時間の都合で「リリース前に1回」が限界だった侵入テストを、ビルドパイプラインに組み込み、毎日回す世界が見えてきます。
決済・金融（FinTech）でのOWASP Top 10の活かし方
決済・金融分野のWebサービスは、取り扱う情報の性質上、Webアプリケーションの脆弱性対策が事業の信頼に直結します。OWASP Top 10は、こうした分野で安全なコーディングや一般的な攻撃への対策を考える際の共通言語として役立ちます。
特に、カード情報や口座情報などの重要データを扱う場面では、A01（アクセス制御の不備）・A02（セキュリティ設定の不備）・A04（暗号化の不備）・A09（セキュリティログとアラートの不備）が、データの保護と不正の早期検知に直結します。これらを優先的に点検することが、サービスの信頼維持につながります。
たとえばPCI DSS（クレジットカード業界のセキュリティ基準）も、安全なソフトウェア開発や代表的な攻撃への対策を求めており、OWASP Top 10と問題意識が重なります。
また、金融機関のシステムには、FISC（金融情報システムセンター）の安全対策基準など、業界で共有されている基準に沿った対策が求められます。Webアプリケーションの脆弱性対策は、そうした全体の取り組みの一部として位置づけられます。
各基準の個別の条項とOWASP Top 10の対応関係は基準の原文で確認する必要がありますが、OWASP Top 10を自己点検の土台に据えることで、業界基準で求められるWebアプリケーション対策の抜け漏れを減らしやすくなります。
自社でどう使うか：自己点検と脆弱性診断サービスの使い分け
OWASP Top 10を把握したら、次は自社のWebアプリケーションが各項目に対応できているかを確認する段階です。確認の仕方は、大きく2つに分かれます。開発チームが自分たちでツールを回して継続的に点検する「自己点検」と、専門家に依頼して攻撃者の視点で深く検査してもらう「脆弱性診断」です。
自己点検は、ソースコードの静的解析や稼働中アプリの動的検査、依存ライブラリやクラウド設定のチェックを、開発の流れに組み込んで日常的に回す使い方に向いています。
一方で、設計上の欠陥や複数の弱点を組み合わせた攻撃経路など、自動ツールだけでは見つけにくい問題や、取引先・監査への報告書が必要な場面では、専門家による脆弱性診断やペネトレーションテストが適しています。多くの場合、自己点検で日常的に穴をふさぎ、重要なリリースや定期点検のタイミングで専門診断を受ける、という組み合わせが現実的です。
では、なぜ診断を一度きりで終わらせず、節目ごとに繰り返す必要があるのでしょうか。MCB FinTechカタログの独自インタビューでは、その背景が次のように語られました。
これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
以下では理解の助けとして、ここまで述べた2つのアプローチ、すなわち自己点検型のツールと専門家による診断サービスの代表例を、1つずつ取り上げます。両者の位置づけの違いは、次の比較表で整理しています。
| サービス名 | Aikido Security | CoWorker 脆弱性診断 |
|---|---|---|
| 診断の方式 | ツール型SaaS （自動スキャンを継続利用） | 受託型の脆弱性診断 （AI解析＋専門家が最終確認） |
| 主な診断対象 | ソースコード・依存ライブラリ クラウド設定・コンテナ 稼働中のWebアプリ | Webアプリ・API ソースコード・設計書 |
| 対応する診断手法 | SAST・SCA・DAST CSPM など | ソースコードAI診断 動的診断 ペネトレーションテスト |
| OWASP Top 10との関係 | アクセス制御・設定・サプライチェーン などの領域を、開発の流れの中で 継続的に点検 | Webアプリ・APIの脆弱性を 専門家の視点で検査 （OWASP LLM Top 10準拠のAI診断も別途提供） |
| 料金目安 | 月額5万円台〜 （年間契約・利用者10人までの場合） 無料のDeveloperプランあり | ソースコードAI診断15万円〜 ソースコード＋動的診断セット50万円〜 |
| 向いているケース | 開発フローに組み込み 日常的に自己点検したい 内製の開発チーム | 自己点検では見つけにくい問題まで 専門家に検査してほしい 報告書が必要な場面 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
Aikido Security
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリケーションを1つの管理画面で検査できる脆弱性診断の統合型SaaSです。
ソースコードの静的解析（SAST）、依存関係のチェック（SCA）、稼働中アプリの動的検査（DAST）、クラウド設定の点検（CSPM）などに対応し、人が診断してレポートを納品する受託型ではなく、自動スキャンを継続的に回す形で使います。OWASP Top 10が示すアクセス制御・設定・サプライチェーンといった領域を、開発の流れの中で日常的に点検したい開発チームに向いています。
アラートの自動トリアージで誤検知を減らし、Slack・Teams・Jira・AWSなどと連携して検出内容を通知できます。
無料のDeveloperプランから始められ、日本では株式会社AndGoが取り扱っており、MCB FinTechカタログの掲載情報（2026年11月時点）では月額5万円台（年間契約・利用者10人までの場合）からの案内となっています。正式な対象機能や料金は契約経路によって異なるため、見積もり時の確認が必要です。
出典・参考資料（1件）
- 参考資料：Aikido Security公式サイト
CoWorker 脆弱性診断サービス（CoWorker株式会社）
自社開発AI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせているのが、CoWorker株式会社の脆弱性診断サービスです。
メニューは、ソースコードをAIが解析する「ソースコードAI診断」、稼働中のWebアプリ・APIを対象とする「動的脆弱性診断」、攻撃を想定した「実践攻撃シミュレーション診断（ペネトレーションテスト）」の3つで構成され、自己点検では見つけにくい問題まで専門家の視点で検査したい場合に向いています。
料金は、MCB FinTechカタログの掲載情報（2026年11月時点）によると、ソースコードAI診断が15万円、ソースコードと動的診断をセットにしたプランが50万円からとなっています（税の扱いは要確認）。
派生サービスとして、生成AI・大規模言語モデル（LLM）を対象とした脆弱性診断（OWASP LLM Top 10に準拠するとしている）も提供されています。AIで開発を進める現場で、生成コードやAI機能そのものの検査まで視野に入れたい場合の選択肢になります。
出典・参考資料（1件）
ここで取り上げたのは、自己点検型と専門診断型それぞれの一例です。診断対象や診断方式、費用の幅はサービスによって異なります。自社の要件に合う依頼先をじっくり比べたい場合は、脆弱性診断サービスを選び方・費用相場・診断方法の観点で横断的に整理した次の記事もあわせてご覧ください。
まとめ
OWASP Top 10:2025は、2025年に公開された現行の最新版です。
全10項目は、A01アクセス制御の不備を筆頭に、A02セキュリティ設定の不備、A03ソフトウェアサプライチェーンの不備、A04暗号化の不備、A05インジェクション、A06安全性を欠いた設計、A07認証の不備、A08ソフトウェアまたはデータの完全性の不備、A09セキュリティログとアラートの不備、A10例外的な状況への不適切な対応で構成されます。
2021年版からの主な変更は、A03とA10の新設、SSRFのA01への統合、セキュリティ設定の不備の順位上昇、そしてA07・A09の改称です。あわせて、本体には入らなかった次点としてAI生成コードへの過信（Vibe Coding）が挙げられた点も、AI活用が進む開発現場では押さえておきたいところです。
まずは自社のWebアプリケーションを各項目に照らして点検し、自己点検で足りない範囲は専門の脆弱性診断サービスに委ねることが、現実的な次の一歩になります。
一括ダウンロードする
よくあるご質問（FAQ）
Q. OWASP Top 10とは何ですか？
A. OWASP Top 10とは、Webアプリケーションにとって特に重大なセキュリティリスクを、重要度順に10項目へまとめた啓発文書です。非営利の国際コミュニティOWASP（Open Worldwide Application Security Project）が無償で公開しており、数年ごとに改訂されています。
2026年11月時点の最新版は、2025年に公開された「OWASP Top 10:2025」です。これを満たせば安全が保証される網羅的なチェックリストではなく、自社のWebアプリケーションの対策状況を確認する出発点として使うものです。
出典・参考資料（1件）
Q. OWASP Top 10の更新頻度はどのくらいで、2025年版が最新ですか？
A. OWASP Top 10は数年ごとに改訂されており、2026年11月時点の最新版は2025年に公開された「OWASP Top 10:2025」です。直近では2017年版・2021年版・2025年版と更新されてきました。固定の改訂周期は定められていませんが、おおむね数年単位で見直されるため、自社のチェックリストやツール設定も最新版の公開に合わせて更新するのが実務的です。
出典・参考資料（1件）
Q. OWASP Top 10:2025はどこで入手できますか？
A. OWASP Top 10:2025は、OWASP公式サイトのプロジェクトページ（top10.owasp.org/2025）で無料で閲覧・入手できます。全10項目の一覧、各カテゴリの個別解説、順位の決め方を説明した方法論（Introduction）、次点カテゴリ（Next Steps）までがWeb上で公開されています。日本語で読みたい場合は、後述の公式日本語版を利用できます。
出典・参考資料（1件）
Q. OWASP Top 10:2025に日本語版はありますか？
A. あります。OWASP公式サイト内に公式の日本語訳（top10.owasp.org/2025/ja/）が公開されています。各項目に公式の日本語名が英語名併記で掲載されており、本記事で用いている日本語名もこの公式訳に沿っています。解説記事によって訳語が割れている場合は、この公式日本語版を確定基準として参照すると迷いません。
出典・参考資料（1件）
Q. OWASP ASVSとOWASP Top 10は、どう使い分ければよいですか？
A. OWASP Top 10は重大なリスクを知るための啓発文書、OWASP ASVS（アプリケーションセキュリティ検証標準）は満たすべき要件を検証可能な形で列挙した標準で、役割が異なります。
Top 10が「避けるべきこと」を10項目で示すのに対し、ASVSは「実装・テストすべき管理策」をより細かく定め、アプリのリスクに応じた検証レベルを段階的に設けています。
OWASPは、Top 10を出発点として使い、そこから先の具体的な検証にはASVSを用いることを勧めています。自社の対策を合否基準で点検する段階に入ったら、Top 10からASVSへ進むのが実務的です。
Q. 2021年版にあったSSRFは、2025年版ではどこへ行ったのですか？
A. 2021年版でA10だったSSRF（サーバーサイドリクエストフォージェリ）は、2025年版では単独カテゴリを廃止し、首位のA01「アクセス制御の不備」に統合されました。A01の対策を点検する際は、サーバーが外部へリクエストを送る処理の宛先制限もあわせて確認します。
統合の経緯や「機微な情報の露出」の行き先は、本文の「SSRF・『機微な情報の露出』はどこへ行ったのか」の見出しで詳しく解説しています。
出典・参考資料（1件）
Q. OWASP Top 10:2025は最終版ですか、今後内容が変わりますか？
A. OWASP Top 10:2025は、リリース候補（RC）か最終版かといった区別の表記が公式に設けられておらず、2026年11月時点で現行の最新版として公開されています。
公式サイト・公式プロジェクトページのいずれも、2025年版を「released（公開済み）」「現行の最新版（most current released version）」として扱っています。したがって、今は2025年版を最新の基準として扱って問題ありません。
Q. OWASP Top 10に対応すれば、PCI DSSなどのセキュリティ基準を満たせますか？
A. OWASP Top 10に対応するだけで、PCI DSSなどの基準そのものを満たせるわけではありません。
OWASP Top 10はWebアプリケーションの代表的なリスクをまとめた啓発文書で、安全なコーディングや一般的な攻撃への対策という点でPCI DSSと問題意識は重なりますが、各基準の個別要件との対応関係は、基準の原文で確認する必要があります。OWASP Top 10は、業界基準で求められるWebアプリケーション対策の抜け漏れを減らすための土台として使うのが現実的です。
Q. OWASP API Security Top 10は、OWASP Top 10と何が違うのですか？
A. OWASP API Security Top 10は、API特有のセキュリティリスクに絞った別プロジェクトで、Webアプリケーション全般を対象とする本記事のOWASP Top 10とは対象範囲が異なります。API連携が中心のシステムでは、Webアプリ向けのTop 10だけでは認証・認可などAPI層に固有のリスクを拾いきれないため、API向けのリストもあわせて参照すると点検の抜けを減らせます。
API層の脆弱性診断の具体的な進め方や、Webアプリ診断では拾いにくい認可の欠陥については、「API脆弱性診断とは？Webアプリ診断で拾えない認可欠陥とサービスの選び方」で解説しています。
Q. モバイルアプリ向けのOWASP Top 10はありますか？
A. あります。OWASPは、モバイルアプリ特有のリスクを扱う「OWASP Mobile Top 10」を、本記事のWebアプリ向けTop 10とは別のプロジェクトとして公開しています。スマートフォンアプリを開発・運用している場合は、Webアプリ向けのTop 10に加えて、端末内のデータ保護やプラットフォーム連携などを扱うモバイル向けのリストも確認するとよいでしょう。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、OWASP Top 10を基準にWebアプリケーションやAPI、ソースコードを点検できる脆弱性診断サービスの最新資料を無料で一括請求できます。診断対象・診断方式・料金を比べて、自社に合う依頼先を検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
