MENU
サイバー攻撃から企業を守る、情報セキュリティの総合サービス | Proactive Defense
  1. ホーム
  2. ブログ
  3. トレーニング
  4. OWASP Top10 2025で学ぶアプリケーションのセキュリティリスク【セキュア開発技術Blog】

OWASP Top10 2025で学ぶアプリケーションのセキュリティリスク【セキュア開発技術Blog】

トレーニング

Securityチーム オーナーの松田です。
2025年12月、ついにOWASP Top 10 2025がリリースされました。前回の2021から約4年、アプリケーションのリスクはどのように変わったのでしょうか？

OWASP Top 10:2025
https://owasp.org/Top10/2025

本記事では、OWASP Top 10についてご紹介するとともに、2025の更新内容を解説します。

目次
Webサイトのセキュリティ対策できてますか？
脆弱性診断なら Proactive Defenseにお任せ。今すぐサービス詳細を見る →

OWASP とは？

OWASP（オワスプ）は「 Open Worldwide Application Security Project 」の略で、ソフトウェアのセキュリティ向上を目的に世界中の専門家が参加するオープンコミュニティです。セキュリティガイドラインの策定や診断ツールの開発など、多様なプロジェクトを推進しています。

OWASP Top 10 とは

OWASP Top 10は、OWASPの象徴的なプロジェクトで最も一般に知れ渡っているものの一つで、Webアプリケーションがよく直面する重大なセキュリティ問題を10個のカテゴリにまとめられています。2003年から数年おきに更新されており、2025年12月には最新版がリリースされました。具体的な攻撃手法のリストではなくても、アプリ開発で起こりがちな「典型的な落とし穴」を分類したガイドラインと捉えると分かりやすいでしょう。

例えば、OWASP Top 10:2025で1位の「アクセス制御の不備」は実装段階で生じやすい問題であり、5位の「インジェクション」は攻撃手法そのものを指します。

つまり、OWASP Top 10は、開発者や設計者がまず押さえておくべき基本的なセキュリティ項目です。社内研修のカリキュラム構成や、自社セキュリティ基準作成などにも活用できる汎用性の高いドキュメントです。特に、OWASP の説明では、開発者とWebアプリケーションセキュリティのための標準的な意識向上文書とされています。

OWASP Top10 2025

OWASP Top10 2025は以下の通りです。日本語訳は、2021版などを参考につけました。翻訳は変わる可能性があります。

  • 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 & Alerting Failures セキュリティログとアラートの失敗
  • A10:2025 – Mishandling of Exceptional Conditions 例外の不適切な処理

不動のTop10であるInjection は今回（2025年版）も Top10 にランクインしています。2017年版では1位、2021年版では3位、そして2025年版では5位と、徐々に順位が下がってきています。これは、Framework やライブラリの標準機能が強化されたことで、Injection 攻撃に脆弱なアプリケーションが以前ほど発生しにくくなってきたためだと考えられます。実際、診断でも検出数が減ってきていると感じます。
とはいえ、5位なので、まだまだ多く見つかっていますね。

スコア表

アプリケーションのセキュリティリスクとはなんでしょうか？
OWASP Top 10 のリスクは、悪用可能性、検出可能性（発生可能性も含む）、技術的影響を基にランク付けされています。

What are Application Security Risks?
https://owasp.org/Top10/2025/0x02_2025-What_are_Application_Security_Risks/

下図は、各カテゴリのパラメータを表にまとめたものです。

CWEs MappedMax Incidence RateAvg Incidence RateMax CoverageAvg CoverageAvg Weighted ExploitAvg Weighted ImpactTotal OccurrencesTotal CVEs
A014020.15%3.74%100.00%42.93%7.043.841,839,70132,654
A021627.70%3.00%100.00%52.35%7.963.97719,0841,375
A0369.56%5.72%65.42%27.47%8.175.23215,24811
A043213.77%3.80%100.00%47.74%7.233.901,665,3482,185
A053713.77%3.08%100.00%42.93%7.154.321,404,24962,445
A063922.18%1.86%88.76%35.18%6.964.05729,8827,647
A073615.80%2.92%100.00%37.14%7.694.441,120,6737,147
A08148.98%2.75%78.52%45.49%7.114.79501,3273,331
A09511.33%3.91%85.96%46.48%7.192.65260,288723
A102420.67%2.95%100.00%37.95%7.113.81769,5813,416

各項目について説明します。

  • CWEs Mapped:
    Top Ten チームによってTop10のカテゴリ(例えば、A01 アクセス制御の不備)にマップされた CWE の数です。つまり、Top10の複数の CWE をグルーピングしたカテゴリとなっています。後続の集計は、このCWE に紐づいている CVEのCVSSスコアを基に算出されています。
  • Incidence Rate:
    検知率(発生率)。組織がその年にテストしたアプリケーションのうち、その CWE に対して脆弱なアプリケーションの割合です。OWASP Top 10では、民間組織からデータを提供されています（組織はこちら）。その組織がテストして脆弱性が見つかったアプリケーションの割合です。この数字が高いほど、多くのアプリケーションで見つかってます。（脆弱性の数ではなく、見つかったアプリケーションの数なので実態に近い数値です。）
  • (Testing) Coverage:
    カバー率。その CWE についてすべての組織によってテストされたアプリケーションの割合です。100%なら、その組織は全てのアプリケーションで、このTop10のカテゴリをテストしていることになります。
  • Weighted Exploit:
    悪用可能性。”攻撃者が実際に攻撃できるかどうか”を数値化したもので、全CVEをならして10点満点で数値化されてます。つまり10に近いほど、悪用しやすいということです。
  • Weighted Impact:
    技術的影響。”攻撃に成功したときにどれほど被害が出るか”を示す指標です。同じく10点満点で数値化されてます。つまり10に近いほど、攻撃されたら被害が大きいということです。
  • Total Occurrences:
    発生総数。Top10のカテゴリの問題が見つかったアプリケーションの総数。総数なので、世界中でどれだけこの問題が見つかっているかを表します。
  • Total CVEs:
    CVEの数。Top10のカテゴリにマップされたCWEと紐づくCVEの総数。CVEは、製品と脆弱性に一意に割り振られた数なので、見つかった脆弱性の数とも言えます。
  • Formula:
    リスクスコアの計算式。(Max Incidence Rate % * 1000) + (Max Coverage % * 100) + (Avg Exploit * 10) + (Avg Impact * 20) + (Sum Occurrences / 10000) = Risk Score

OWASP Top 10 2025　カテゴリごとに解説します

さあ、ここからは OWASP Top 10 2025 の各カテゴリを見ていきましょう。

A01:2025 – Broken Access Control アクセス制御の不備

このカテゴリは、2021も1位でした。ここ数年特に危険度が高い問題として、報告されています。

CWEs MappedMax Incidence RateAvg Incidence RateMax CoverageAvg CoverageAvg Weighted ExploitAvg Weighted ImpactTotal OccurrencesTotal CVEs
A014020.15%3.74%100.00%42.93%7.043.841,839,70132,654

スコアで特筆すべきは、Total Occurrences が1位であることです。つまり、Top10のカテゴリの中で、最も多くのアプリケーションで指摘されている問題です。

具体的に、アクセス制御の不備とはどんなものでしょうか？

例えば、以下のURLで自分の個人情報が見られたとします。

https://example.com/app/accountInfo?id=10001

しかし、以下のようにidパラメータを変更すると他人の個人情報が見れた場合、アクセス制御の不備と言えます。

https://example.com/app/accountInfo?id=10002

別の例では、以下のURLは管理者しかアクセスできない内容が表示されるURLです。

https://example.com/admin/app/getappInfo

これを、直接ブラウザに入力すると管理者権限のないユーザでも内容が表示される。もしくは

$ curl https://example.com/admin/app/getappInfo

とコマンドラインから実行するだけで、内容が取得できる場合、アクセス制御の不備がある状態と言えます。

アクセス制御が最も多く問題になる理由

アクセス制御の不備は、特に認可の不備と言えるかもしれません。なぜ、この問題が、最も多くのアプリケーションで見つかっているのでしょうか。

おそらくは、Frameworkやライブラリ、仕組みで防ぐことが難しいためだと思います。権限判定ロジックは、アプリケーションごとに異なります。上述したように、明らかに問題として指摘できるものを除き、アプリケーションごとに設計し、その設計通りに実装もしくは設定し、テストするという工程が必要です。

そのため、つまり、「Frameworkやライブラリ、仕組みを適用したから大丈夫」ではなく、アプリ固有の設計・実装に依存するため、不備が起きやすい のです。そのため、多く見つかっているのではないでしょうか。

アクセス制御を正しく実装するために必要なこと

防ぐ方法としては、アクセス制御のルールをできる限り明確にすることです。上述のような、誰でもわかるやろ？という内容は、ドキュメントに明示されないケースがあります。それでは、実装できません。

アクセス制御については、アクセス制御ルールをドキュメントにしっかり明示することが重要です。

A02:2025 – Security Misconfiguration セキュリティの設定ミス

2021年版では5位だった 設定ミス（Security Misconfiguration）は、2025年版で2位へ大きくランクアップしました。その背景には、「ノーコード、ローコードに代表されるようにアプリケーションを実装せずに、設定で構築する機会が増えた」 という環境の変化があります。ノーコード／ローコードの普及に加え、クラウド環境では設定だけで動作環境を構築できるようになりました。つまり、設定を行う機会が増えた分、設定ミスが起こる可能性も高くなったと考えられます。

セキュリティの設定ミスの具体例

代表的な例を以下に挙げます。

  • デフォルトのアカウントをそのまま使い続けている
  • 本番環境に不要なサンプルアプリケーションが残っている
  • サーバーでディレクトリ一覧表示が無効化されていない
  • スタックトレースなど詳細なエラーメッセージがユーザーに返される
  • クラウドストレージが「公開設定」になっており機密データが漏洩する
  • サーバーがセキュリティヘッダー（例：CSP、HSTSなど）を送信していない
  • 公開範囲の設定を誤り、管理者情報が一般ユーザーから見えてしまう

これらは、「単純な設定漏れ」 から 「正しいと思っていた設定が実はベストプラクティスに反していた」 という知識不足に起因するものまで、幅広い原因で発生します。

セキュリティの設定ミスを防ぐために必要なこと

防ぐためには、設定のレビュー、できればAWS SecurityHub CSPMのように設定を自動でレビューしてくれるCloud Security Posture Management(CSPM)のようなツールでレビューを実施すること、また各設定のベストプラクティスを知ることが重要です。

A03:2025 – Software Supply Chain Failures ソフトウェアのサプライチェーンリスク

このカテゴリは、コミュニティ調査でトップにランクされ、50%の回答者が第1位に選んだようです。2021年版の A06:2021 – Vulnerable and Outdated Components（脆弱で古くなったコンポーネント）を拡張したカテゴリで、既知の脆弱性に限らず、ソフトウェアサプライチェーン全体に関わるリスクが対象となっています。

近年最大級のサプライチェーン攻撃：Shai-Hulud 2.0攻撃

最近の事例として特に大きな影響を与えたのが、npmエコシステムを狙った 「Shai-Hulud 2.0攻撃」ではないでしょうか。自己増殖型の攻撃で、700以上のnpmパッケージが侵害されました。侵害されたパッケージをインストールすると、npmの認証情報をはじめ、AWSやAzure、GCPなどの認証情報を取得しようと動作します。弊社でも、一時npmの利用を停止するなど、対応に苦慮しました。

出典：GitHub Security Blog「Our plan for a more secure npm supply chain」
https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/
GitHub Security Blog「Strengthening supply chain security: Preparing for the next malware campaign」
https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/

あわせて読みたい
npmサプライチェーン攻撃Shai-Huludの起点はフィッシング～TOTPの代わりにFIDOで対策を～【セキュア開発… Securityチーム オーナーの松田です。2025年9月に起きたShai-Hulud攻撃とその対策について記事を書きました。皆様のご参考になれば幸いです。 今回の記事概要 2025年9月…

代表的なサプライチェーン攻撃：SolarWinds事件

もうひとつ有名な例が 2019年の SolarWinds 侵害事件 です。
ソフトウェアベンダー自身がマルウェアに感染し、アップデートのタイミングで約18,000組織へ侵害が広がったとされています。

出典：NPR　「A “Worst Nightmare” Cyberattack – SolarWinds Hack」
https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack

コンポーネントの脆弱性と放置のリスク

もちろん、コンポーネントの脆弱性に関するリスクも含まれます。Webアプリケーションの開発では、Open Source Software(OSS)の利用は欠かせないものです。そのOSSに重大な脆弱性が発見されることもあります。そういった脆弱性に対処しないで放置することも、このカテゴリの問題となります。

例えば、2025年12月には、人気のフレームワークである、ReactやNext.jsに、「React2shell」と呼ばれる脆弱性(CVE-2025-55182, CVE-2025-66478)が、発見されました。リモートコード実行が可能という、非常に危険な脆弱性であったため、迅速な対応が求められました。

また、特に、最近IoT機器が増えてきました。IoT機器は、パッチの適用が困難または実質不可能なこともあり、このカテゴリのリスクを増加させているかもしれません。

出典：React 「React Server Components における重大なセキュリティ脆弱性」
https://ja.react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
Next.js「Security Advisory: CVE-2025-66478」
https://nextjs.org/blog/CVE-2025-66478

サプライチェーンリスクを防ぐために必要な対策

この問題を防止するためには、利用するコンポーネントを適切に把握することです。コンポーネントとは、ライブラリ、Framework、パッケージ、OS、ミドルウェア、Saasサービスなど、システムを構成する部品を指しています。

また、利用するコンポーネントのEnd of Life ( EoL )やライセンスを管理することも欠かせません。

Software Composition Analysis ( SCA ) のようなツールに頼ることになると思いますが、システム全体のコンポーネントを適切に管理できるようなツールを選定してください。できれば、1つのツールで把握したいですね。

A04:2025 – Cryptographic Failures 暗号化の失敗

暗号化の失敗は、2つ順位を下げて4位になりました。このカテゴリには、暗号化をすべきなのにしていない、強度不足の暗号方式を使っている、暗号鍵の漏えい、およびその関連する問題が含まれています。特筆すべきは、1,665,348 のアプリケーションで見つかっているように、OWASP Top 10のなかで2番目に多くのアプリケーションで見つかっている点です。

TLS設定の不備がもっとも多い

主な問題は、SSL/TLS通信をしていないもしくは不適切な設定になっていることです。例えば、SSL/TLS通信には、バージョンがあり、SSL1.0→SSL2.0→SSL3.0→TLS1.0→TLS1.1→TLS1.2→TLS1.3と続きます。現在は、TLS1.2以上が推奨されますので、それ以外のバージョンが許可されている場合、暗号化の失敗と言えます。
推奨される設定は、独立行政法人 情報処理推進機構(IPA)が発行する「TLS暗号設定ガイドライン」を参考にするとよいでしょう。

出典：IPA 「TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編）」https://www.ipa.go.jp/security/crypto/guideline/ssl_crypt_config.html

転送中のみならず、暗号化して保存する場合にも失敗のケースがあります。例えば、パスワードを保管する際に、ソルトがなくMD5 や SHA1 などの非推奨のハッシュ関数を使われている場合、暗号化の失敗と言えます。パスワードを保管する場合は、Password Storage Cheat Sheet を参考に適切なハッシュ関数を選択してください。

出典：OWASP「OWASP Cheat Sheet Series」
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

その他、暗号鍵・暗号キーの露出（例えばソースコードに暗号鍵がハードコードされておりコードリポジトリから漏れてしまう）、などがあります。

暗号化の失敗を防ぐために必要な対策

この問題を防止するためには、まず全ての通信は暗号化してください。FTPやSMTP など暗号化されていないプロトコルは使わず、必ず暗号化して通信してください。

次に、暗号化する必要があるデータを特定してください。例えば、パスワードはハッシュ化して保存が必要です。個人情報を保管する場合も暗号化が求められるでしょう。

保管する際に暗号化が必要なデータを特定し、その要件に沿った適切な暗号化方式を選択してください。多くのDBやクラウドストレージは、暗号化の機能を提供していますので利用するといいと思います。

A05:2025 – Injection インジェクション

インジェクションは、2021版の3位から5位にランクダウンしました。このカテゴリは非常に幅広いカテゴリで、クロスサイトスクリプティング(XSS)、SQLインジェクション、XMLインジェクションなど、37のCWEがマッピングされています。このインジェクションは、不動のTop10で、OWASP Top 10が出た2003年から、ずっとTop10にランクインしています。古くからありますが、未だ発生しており、また発生すると非常に危険度の高い問題です。

代表例：SQLインジェクション

インジェクションと言えば、有名なのがSQLインジェクションではないでしょうか。

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

上記の例では、id パラメータには、顧客IDを期待しています。しかし、id パラメーターにSQL文(例 ‘ OR ‘1’=’1)を指定されるとどうでしょうか？全く別の意味のSQLになり、この例では、１件のaccount情報を取得するつもりが、全件のaccout情報を取得してしまいます。

このように、元々プログラムに実装されているSQLを、パラメータなどからSQL文を注入することにより、本来意図しないSQLとして実行する攻撃をSQLインジェクション攻撃といいます。対象レコード以外の情報を閲覧されたり、他のテーブルの情報を閲覧されたり、DBの全体のバックアップを取得されたり、deleteを使ってデータ消されたりする、非常の危険な攻撃です。

インジェクションを防ぐために必要な対策

防止方法は、データと命令(SQLなど)の分離です。

以下のようにプリペアードステートメントを利用し、データが入る場所を?で明示しましょう。
?には、データしか入らないので、命令(SQL)が入った場合、実行時に適切にエスケープすることができるようになります。ORMを使うのも有効な手です。

String query = "SELECT * FROM accounts WHERE custID = ?";
PreparedStatement pstmt = conn.prepareStatement(query);
pstmt.setString(1, request.getParameter("id"));
ResultSet rs = pstmt.executeQuery();

その他のインジェクションも本質は同じです。データと命令を分離し、データを入れる箇所をパラメータ化することにより、データを適切にエンコード、エスケープします。間違っても、文字列結合で、SQLやコマンドを構成しないでください。

なお、LLMに対するインジェクションとして有名なプロンプトインジェクションについては、OWASP LLM Top 10 のLLM01:2025 Prompt Injection を参照してください。

A06:2025 – Insecure Design 安全が確認されない不安な設計

4位から6位に順位を下げました。2021版にて初めて導入されたカテゴリです。2021年版に導入されたことをきっかけに、脅威モデリングとセキュア設計を通じて、業界全体で改善が見られたため、順位が下がったようです。
このカテゴリは、設計およびアーキテクチャの欠陥に関するリスクに焦点を当てられ、脅威モデリング、セキュア設計パターン、リファレンスアーキテクチャの活用が不足していることを指摘しています。これには、アプリケーションのビジネスロジックの欠陥（ 例：アプリケーション内の望ましくないまたは予期しない状態変化の定義不足 ）が含まれます。

この問題を防止するためには、要件定義やアプリケーション設計に、セキュア・バイ・デザインの原則を適用する必要があります。最も注目したいのは、「安全でない設計は、完璧な実装では修正できない」ということです。

安全ではない設計の具体例

例えば、安全でない設計とは、以下のような内容です。

  • パスワードを忘れた際に、パスワードを回復する手段として、「秘密の質問と回答」だけでパスワードを回復できる
  • ある映画館チェーンで、団体予約の際に最大 15 名までは予約保証金が必要ありません。これを悪用し数回のリクエストで600席を予約することで損失を引き起こすことができます
  • 適切なボット対策をしていないため、転売目的のボットに買い占められ、店舗の評判がさがってしまう

どうでしょうか？実装でカバーすることは難しいと思います。要件定義や設計段階からセキュリティを考慮に入れる必要があります。

安全ではない設計を防ぐために必要な対策

この問題の防止方法としては、リファレンスアーキテクチャ・安全な設計パターンの採用、認証や、アクセス制御、ビジネス ロジックなどのアプリケーションの重要な部分に脅威モデリングを実施することがあげられます。

いずれも、ツールやライブラリのようにアドオンできるようなものではなく、安全な開発ライフサイクルを構築するため組織としての対応が必要です。安全なソフトウェア開発組織を構築するには、 OWASP Software Assurance Maturity Model (SAMM) の活用をご検討ください。

あわせて読みたい
セキュア開発を実現するには？現場における課題とKDLでの取り組み【セキュア開発技術Blog】 セキュアなシステムを開発するには、セキュリティの知識やルールをきちんと踏まえて進めることが欠かせません。そのため当社神戸デジタル・ラボ（以下KDL）では、開発者…

A07:2025 – Authentication Failures 認証の失敗

名称が変わったものの、2021版と同じ7位にランクインしました。認証については、多くのアプリケーションで標準化された Framework を使ったり、IdPのようなサービスを利用し、独自に実装することはなくなったのではないかと思いますが、それでも変わらず7位という点に注目する必要があります。

認証の失敗の具体例

認証の失敗とは、攻撃者がシステムをだまし、なりましができてる状態を指します。例えば、総当たり攻撃により、パスワードを解析してログインできることです。他にも既知のユーザー名とパスワードの組み合わせリストを大量に試す クレデンシャルスタッフィング攻撃 があります。これは、「パスワードを唯一の認証要素として使い続けている」ことが原因と言えます。

重要なシステムでは 多要素認証（MFA）、2段階認証を必ず利用すること が推奨されています。

別の例として、公共のコンピュータでシングルサインオン（SSO）を利用しているケースがあります。
SSO は一度ログインすると複数のサービス（メール、ドキュメント、チャット等）に自動でログインできますが、シングルログアウト（SLO）が正しく動作しないと、ログアウトしたつもりでも 一部のサービスのセッションが残ってしまう ことがあります。

その状態で次の利用者が同じブラウザを使うと、被害者のアカウントにアクセスできてしまう危険があります。
企業内でも、共有端末などでログアウトが完全に実施されず、同僚が意図せずアクセスできてしまう、といった問題が起こりえます。

認証情報は狙われています

A03:2025 – Software Supply Chain Failures ソフトウェアのサプライチェーンリスクで記載した、Shai-Hulud 2.0攻撃でも、認証情報が狙わました。開発者の方は、AWSアクセスキーやシークレットアクセスキーなどの長期認証情報を保管していたりします。この認証情報が狙われました。

認証の失敗とは、少し違うかもしれませんが、認証情報の適切な管理は、非常に重要です。長期認証情報を利用せず、有効期限のついた短期的なトークンなどを利用しましょう。

認証の失敗を防ぐために必要な対策

実装における認証の失敗は減ったかもしれませんが、設定の不備によって発生する認証の失敗は、まだまだあります。
標準化された Framework やIdPなどの認証サービスを利用しつつ、多要素認証、2段階認証を導入する（強制しなくとも）、セッションタイムアウトを適切に設定する、ログアウトした際に適切にセッショントークンを無効化する、などの対策を実施してください

A08:2025 – Software or Data Integrity Failures ソフトウェアとデータの整合性の不具合

引き続き8位にランクインされています。ソフトウェアもしくはデータの整合性の不具合とは、「信頼できないコードやデータが、正当なものとして扱われてしまう」 状態を指します。またそのための保護が欠落していることです。

ソフトウェアとデータの整合性の不具合の具体例

例えば、アプリケーションが、信頼できない提供元からライブラリをダウンロードして使っている場合などが挙げられます。ソフトウェアの整合性チェック（例えば署名の検証）を実施していない場合、侵害されたコードをアプリケーションに適用してしまう可能性があります。

他には、多くのアプリケーションには現在、自動更新機能が搭載されています。この自動更新機能が、十分な整合性検証なしにアップデートを適用することで、以前は信頼されていたアプリケーションが、知らぬ間に侵害される可能性があります。
最後に、シリアライズされたオブジェクトまたはデータが、攻撃者が参照および変更できるわかりやすい構造になっている場合、安全でないデシリアライゼーションに対して脆弱になります。

つまり、信頼して受け入れたソフトウェアやデータが改ざんされ、悪意のあるものに変更されているリスクを指摘しています。

ソフトウェアとデータの整合性の不具合を防ぐために必要な対策

防止策として最も重要なのは、ソフトウェアやデータの真正性を確認することです。
デジタル署名などの仕組みを利用し、提供元が正しいか、改ざんされていないかを必ず検証してください。
あわせて、npm や Maven といった依存パッケージは、信頼できる公式リポジトリからのみ取得するようにしましょう。

さらに、ビルドやデプロイのプロセスが攻撃されると、安全なソフトウェアにも不正コードが混入してしまう可能性があります。そのため、CI/CD パイプラインを適切に分離・構成し、アクセス権限を厳格に管理することが不可欠です。

加えて、信頼できないクライアントから送られるシリアライズされたデータは受け入れないようにしましょう。
たとえば Cookie にシリアライズされたデータを保存している場合、Cookie は容易に改ざんできるため、そのデータを信用して処理してはいけません。デジタル署名などで改ざん検知ができない場合は、シリアライズされたデータを受け取らない設計にすることが望まれます。

A09:2025 – Security Logging & Alerting Failures セキュリティログとアラートの失敗

このカテゴリも9位をキープしました。このカテゴリは、データでは常に過小評価されています。つまり、発生総数も低く、技術的影響も最も低いため軽視されがちです。しかし、コミュニティアンケート参加者からの支持により、3度目のランクインとなりました。

このカテゴリは、テストで見つけづらい点も特徴的です。見つけづらいにも関わらず、ログとアラートに失敗すると、アラートが飛ばず、フォレンジック調査しても何も見つからないといった事態になり、俗にいう詰んだ状態になります。そのため、ログとアラートについて、開発時から設計しておくことは非常に重要です。

ログとアラートの失敗の具体例

OWASP Top 10 の攻撃シナリオにて非常に恐ろしいシナリオが紹介されています。ある小児医療保険会社のウェブサイトで、2013年から7年以上にわたってデータを侵害されており、350万以上の医療記録にアクセスされていた可能性があります。システムのログ記録や監視が不十分であったため、侵害に気づかなかったということです。

ログとアラートの失敗を防ぐために必要な対策

この問題を防止する方法としては、ログを残そうということです（当たり前ですね）。
では、いつログを残せばいいのでしょうか？それには、ASVSやチートシートを参照してください。

例えば、以下のようなイベントの際にログを残すことが挙げられています。ぜひ、リファレンスを読んでみてください。

  • 全てのログインイベント
  • 入力検証の失敗
  • アクセス制御の失敗
  • スーパーユーザでの操作
  • 重要な機能に対する操作

A10:2025 – Mishandling of Exceptional Conditions 例外の不適切な処理

2025版 であらたに追加されたカテゴリです。まだ、読み込んで日が浅いため、筆者の理解の範囲になってしまいますが、このカテゴリは、throwされた例外を適切に catch しないことを指摘した問題です。適切に catch しないことで、エラーとして扱えないため、例えば、ログには「何らかのエラーが発生した」という意味のない情報しか残っておらず、例外の原因がわからなくなってしまいます。また、それがトランザクション中であれば、ロールバックされないという問題が起こる可能性を指摘しています。

例外の不適切な処理を防ぐために必要な対策

例外を適切に処理するには、そのような状況に備える（最悪の事態を想定する）必要があります。できれば、例外が発生した場所で直接 catch して対処したいです。対処の一環としては、ユーザにわかりやすくエラーを通知する、イベントをログに残す、場合によってはアラートを出す、などです。また、万が一見落とした場合に備えて、グローバル例外ハンドラーも準備しておきましょう。

もちろん、例外が発生することを未然に防げるとなおよいと思います。可能な限りレート制限、リソースクォータ、スロットリングなどの制限を設けてください。無制限に利用できるというのは、DoS攻撃につながり、予期せぬエラーにつながります。これに加えて、厳格な入力検証、集中的なエラー処理、ログ記録、監視、アラート、そしてグローバルな例外ハンドラーを組み込むとよいと思います。

筆者自身、このカテゴリってセキュリティなのか？と思っています。この記事執筆時点では、まだわかりかねていますので、引き続き調べたいと思います。

最後に

OWASP Top 10は重要なリスクに対する意識向上を目的とした、啓発ドキュメントです。アプリケーションセキュリティに取り組み始める人達に向けた、まずこの10個から始めてくださいという、出発点です。

例えば、OWASP Top 10に基づいた脆弱性診断を実施します、といってもおそらくできません。「A06:2025 – Insecure Design 安全が確認されない不安な設計」なんて、抽象度が高すぎて、テストは困難です。脆弱性診断に使うのであれば、OWASP ASVSやOWASP Web Security Testing Guideが利用できます。

私がお勧めしたいのは、セキュア開発を始める際に、アプリケーションにはどんなセキュリティリスクがあるのか？を学ぶためのドキュメントとして利用することで、セキュア開発の第1章に使うとよいと思います。例えば、インジェクション攻撃というものを知らなければ、エンコードとエスケープの必要性が理解できないかもしれません。アクセス制御について、他人の個人情報が見れているという状況が多く発生していることを知らなければ、対策しないかもしれません。

OWASP Top 10を使ってリスクを理解することで、セキュア開発を始める第一歩に使っていただければと思います。

セキュアなシステム開発についての
＼　無料相談受付中！　／

お問い合わせ/ご相談はこちら
この記事を書いた人
松田　康司

株式会社神戸デジタル・ラボ
デジタルビジネス本部　Securityチーム オーナー / 生産技術チーム

神戸大学情報知能工学科卒。2014年にKDLに入社。自社で構築するECサイトのほぼすべてのプロジェクトに関与しながら、多くの開発プロジェクトを経て、現在はSecurityチーム オーナーと全社のセキュア開発を推進する生産技術チームを兼任。開発部門主導のセキュア開発を実践している。
コミュニティ活動として、OWASP Kansaiボードメンバー、アルティメットサイバーセキュリティクイズ実行委員を務める。

参考文献

トレーニング
  • URLをコピーしました！
目次