
はじめに
こんにちは。GMO Flatt Security株式会社の @toyojuni です。
弊社は "エンジニアの背中を預かる" をミッションにさまざまな開発組織のセキュリティをサポートしていますが、その主たるサービスがWebアプリケーション・Web APIの脆弱性診断です。今回、この脆弱性診断サービスの中でお客様に報告した1000個以上の脆弱性データをもとに、検出数ランキングの形でそのリスクの実態を分析しました。
同様にWebアプリの脆弱性を分析したものとしてはOWASP Top 10が世界的に有名ですが、グローバルでの分析結果となると日本企業の実態にそのまま当てはまるとは限りませんし、自分ごととして考えづらい面もあると思います。
そこで今回は、日本企業のWebセキュリティのリアルなリスクをお伝えすることを目的に、独自調査レポート「GMO Flatt Security Top 10」を公開します。
- はじめに
- データの前提条件
- 2025年版 Top 10
- 2025年版 Top 10 - 深刻度「High」「Critical」のみ
- 上位3個の脆弱性に関する説明
- 調査結果の分析
- 開発組織が取るべきアクション
- 終わりに
データの前提条件
以下の条件のもと脆弱性カテゴリごとに分類しました。
- 弊社サービス「脆弱性診断」においてWebアプリケーション・Web APIを対象に発見された脆弱性
- 2023年1月1日~2024年12月31日に開始・完了した脆弱性診断が対象
- 脆弱性の深刻度評価において「informational」と評価されたものは除外
2025年版 Top 10
上記の条件に基づいて集計し、以下のような結果になりました。各脆弱性の全体に占める割合(%)を少数第一位で四捨五入しています。

| No. | 脆弱性名 | 検出された脆弱性全体に対して占める割合 |
|---|---|---|
| 1 | 認可制御不備 | 28% |
| 2 | 認証の設計・実装不備 | 17% |
| 3 | ロジックの脆弱性(認証・認可以外) | 13% |
| 4 | XSS / クロスサイト・スクリプティング | 9% |
| 5 | セキュリティヘッダの設定不備 | 5% |
| 6 | DoS | 5% |
| 7 | システム情報の漏洩 | 4% |
| 8 | CSVマクロインジェクション | 3% |
| 9 | CSRF / クロスサイト・リクエストフォージェリ | 3% |
| 10 | Cookieのセキュリティ設定不備 | 2% |
2025年版 Top 10 - 深刻度「High」「Critical」のみ
上記のデータは脆弱性深刻度評価において「informational」を除いているとはいえ「Low」「Medium」「High」「Critical」の全てという幅広い範囲を対象にした、検出数のみを基準とするランキングです。ともすると、重大なリスクに結びつく脆弱性の順位を正確に表していないかもしれません。
そこで、脆弱性深刻度を「High」「Critical」のみに絞ったデータを以下に示します。

| No. | 脆弱性名 | 検出された脆弱性全体に対して占める割合 |
|---|---|---|
| 1 | 認可制御不備 | 25% |
| 2 | 認証の設計・実装不備 | 15% |
| 3 | XSS / クロスサイト・スクリプティング | 14% |
| 4 | ロジックの脆弱性(認証・認可以外) | 10% |
| 5 | CSVマクロインジェクション | 5% |
| 6 | DoS | 5% |
| 7 | Cookieのセキュリティ設定不備 | 4% |
| 8 | 脆弱なミドルウェアの使用 | 4% |
| 9 | システム情報の漏洩 | 3% |
| 9 | CSRF / クロスサイト・リクエストフォージェリ | 3% |
※「システム情報の漏洩」「CSRF」は同率9位
※ 以下特に断りがない場合、順位に言及する時は深刻度を絞り込んでいない結果を参照します。
上位3個の脆弱性に関する説明
認証・認可はともかくとして、ロジックの脆弱性は耳慣れない方もいると思います。以下ではTop 10上位3個の脆弱性を簡単に解説します。
1位: 認可制御不備
認可制御とは、Webアプリケーションのユーザーに対して、付与されたアクセス権限通りの操作のみを許し、それ以外の操作を禁止する制御のことです。
そのような制御があるべき箇所に実装されていなかったり、制御を迂回して本来禁止された操作を実行できたりしてしまう脆弱性を「認可制御不備」と呼びます。脆弱性が存在すると、一般ユーザーでありながら全ユーザーの個人情報が閲覧できてしまうなど、情報漏洩をはじめとする様々なリスクに直結します。

2位: 認証の設計・実装不備
認証の設計・実装不備とは、ログイン、ログアウト等の認証を提供する部分の機能に関する不備を分類したものです。具体的には以下のような脆弱性をこちらに分類しています。
- ログインフォームへのブルートフォース対策が取られていない
- ログインフォーム機能のレスポンスの差分からメールアドレスの存在が確認可能
- 多要素認証のため導入されているPIN入力機能の実装不備
3位: ロジックの脆弱性
今回の結果で分類している「ロジックの脆弱性」とは、サービスの仕様上では想定されていない動作を引き起こすことで問題となりうるものを指しています。以下のようなサービス固有のビジネスロジックに反するものが例として挙げられます。
- 有料限定コンテンツの制限を回避した閲覧
- 回数制限のある機能の制限回避
- リンクで共有する機能が発行するURL等の文字列が推測可能
また、認証・認可の仕様もサービス固有のビジネスロジックであるため、認可制御不備と認証の設計・実装不備も広義のロジックの脆弱性と言うことができます。そのため、今回「ロジックの脆弱性(認証・認可以外)」と表現しています。
なお、ロジックの脆弱性そのものや認証/認可/それ以外といった分類は、以下のようにデジタル庁が公開している資料でも同様の(と解釈できる)定義がされているため、一定専門家の間でも似たような認識がなされているとは思います。しかし明確な統一見解があるともいえないため、あくまで「GMO Flatt Securityの定義におけるもの」として本記事はお読みください。

調査結果の分析
前置きが長くなってしまいましたが、結果の分析に移ります。
1. 認可制御不備が最大のリスク
すでにご覧いただいた通り、認可制御不備が圧倒的1位となり、2位以下に大きく差をつける結果となりました。
認可制御不備はOWASP Top 10の最新2021年版でも第一位のリスクとされていることからも、これは弊社の調査によって偏った結果が出ていると言うわけでもなく、名実ともに最大のリスクと言えるでしょう。
認可制御不備の解説とその対策は弊社技術ブログで公開済みですので、ぜひこちらをご覧ください。
2. 認証・認可含むロジックの脆弱性が約6割を占める
弊社が広義のロジックの脆弱性と分類するものの比率の合計は58%となりました。高機能化・複雑化の一途を辿る現代のアプリケーションにおいて妥当な結果と思われますが、このような偏りには弊社特有の要因もあると感じます。
それを以下の3つに分類し、分析してみます。
- プロダクトの要因
- 学習環境の要因
- 診断ベンダーの要因
プロダクトの要因
弊社が普段脆弱性診断をする対象のアプリケーションはBtoB SaaSが非常に多くなっています。BtoB SaaSでは利用者の属性によって利用可能な機能が異なっていたり、複数事業者のデータが同一のデータベース等を共有するマルチテナント方式で運営されていたり等、比較的複雑な構成になっていることがあります。
また、固有のビジネスロジックが強く意識される機能を備えている事が多く、それが迂回または破壊されることで大きなリスクとなりうるようなサービスもあります。 このような点から、BtoB SaaSでは一般的なWebアプリケーションと比較して、潜在的に存在するロジックの脆弱性の数自体が多くなっているのではないかと考えられます。
学習環境の要因
開発者がWebセキュリティを学ぶことは重要だと考えている人は多いですが、実際にWebセキュリティを体系的に学ぶ機会が十分に提供されているとは言い難いです。特にロジックの脆弱性に関してはその性質上体系的にまとめることが難しく、情報が少ないです。
このため、どのような実装が脆弱性につながるかといった知識や、そのような脆弱性への対策方法のノウハウが開発組織に十分に浸透していないというのもロジックの脆弱性が生まれやすい原因だと考えられます。
診断ベンダーの要因(GMO Flatt Securityの要因)
GMO Flatt Securityでは技術力の高いエンジニアが診断対象Webサービスの特性の理解に努め、その上でビジネス上の脅威になりうる攻撃観点を考え脆弱性診断を行っています。技術力の裏付けになる実績を一部紹介すると、世界最大級の脆弱性リサーチコンテスト「Pwn2Own」でメンバーがUbuntuの脆弱性を報告し3万USドルの賞金を獲得したり、またメンバーたちが報告しCVEが採番された脆弱性100個以上をWebサイトで公開していたりします。
そのため、フレームワークやライブラリの活用が進んだ昨今の開発体制の中でも、それらが提供している防御機構だけでは防げないような脆弱性を多く発見できる結果に繋がっていると考えられます。
他にも、限られた時間の中でビジネスリスクの大きい脆弱性から見つけていくプランの提供があるため、ロジックの脆弱性のような大きなリスクに結びつきやすい脆弱性が優先的に調査されていることも結果に影響を与えていると思われます。
3. XSSは多くの開発者の予想に反して大きなリスクとして残存
XSS(クロスサイト・スクリプティング)が4位にランクインしていることに驚いた方もいるのではないでしょうか。しかも深刻度を絞った結果では3位に浮上してきます。本ブログの公開前にEMConf JP 2025というイベントで調査結果に関するヒアリングを実施していたのですが、そこでも同様に驚かれた方が多かったです(認証・認可が上位であることにはある意味驚きはなかったとも言えます)。
XSSは脆弱性としての知名度としては9位のCSRFやランク外のSQLインジェクションと同程度あると思われます。そのため、XSSも同様に駆逐されて検出数は少ないと想定されている方が多かったのでしょう。
XSSに関して学ぶにあたっては以下の弊社ブログ記事が人気です。
4. セキュリティヘッダの設定不備の順位の捉え方は要注意
結局、脆弱性の深刻度による絞り込み前後で大きな結果の変動はあまりありませんでした。その中で5位→ランキング外になったセキュリティヘッダの設定不備は最も変動が大きかったと言えるかもしれません。
これらの不備は自動的な検出が容易であり検出数が増える一方、大きなリスクには直結しづらいと言えます。
5. ランク外の脆弱性について
Top 10という結果には示されませんでしたが、以下のような脆弱性も一定数検出されています。
- SQLインジェクション
- ディレクトリトラバーサル
- OSコマンドインジェクション
このような脆弱性は、1件でも実際に攻撃可能なものが見つかった場合には非常に危険なため、報告数が少なくとも無視できるものではないと考えられます。
これらの体系化しやすい脆弱性は学習が可能ですし、それにより大きなリスクを防ぐことができます。同時に、ロジックの脆弱性を発見・対策するための基礎力のようなものも養うこともできるでしょう。GMO Flatt Securityは「KENRO」という学習プラットフォームを提供しており、Webアプリケーションのセキュアコーディングの基礎を学ぶことが可能です。
トライアルは無料・無期限で利用可能ですので、ぜひ下記のバナーよりご登録ください。
開発組織が取るべきアクション
今回の結果をうけてWebサービスの開発で脆弱性をできるだけ減らすにはどのようなアクションを取るべきかを考えてみます。
内部的なアクション
まず開発組織の中で起こせるアクションとしては開発組織内部でのプロダクトセキュリティ知識の獲得、ノウハウの共有です。
Webセキュリティの基礎知識を体系的に学ぶために良いものとしては、IPAが公開している「安全なウェブサイトの作り方」というコンテンツであったり、書籍であればやが挙げられます。
また、弊社でも先ほどご紹介したように「KENRO」を展開していたり、ブログにて「Webサービスの機能とセキュリティ」というカテゴリを設け、主にロジックの脆弱性に関する内容の記事を公開しています。
外部的なアクション
開発者がセキュアコーディングの知識を備え実装することで確かに脆弱性を減らすことはできますが、ロジックの脆弱性のような、体系化できない高度なリスクまで完全に無くすことは難しいです。そのため、外部の専門家や脆弱性診断を活用することが重要と言えます。
終わりに
ここまでお読みいただきありがとうございました。今回の調査結果をぜひ今後の開発の参考にしていただければ幸いです。
GMO Flatt Securityとしては今回挙がったリスクに開発組織の皆様がより的確に対処できるよう、脆弱性診断サービスの改善に努めてまいります。

ご興味を持ってくださった方は以下よりお気軽にお問い合わせください。
また、GMO Flatt Security はセキュリティに関する様々な発信を行っています。 最新情報を見逃さないよう、公式X のフォローをぜひお願いします!