OWASP Top 10 2025で何が変わった？Webアプリケーションセキュリティの最新リスクを整理してみた

はじめに

こんにちは！私はプラットフォーム・サービス部のステイサムです。

先日、OWASP Top 10の項目に基づいた診断ができる脆弱性診断ツールを扱う機会がありました。以前からOWASP Top 10という名称や、SQL Injectionといった代表的な脆弱性についてはある程度理解しているつもりでしたが、昨年2021年版から2025年版へ更新されたこともあり、この機会に改めて内容を確認してみました。本記事では、2021年版からの変更点を確認しながら、開発者・インフラ・セキュリティ担当者が押さえておきたいポイントを整理します。

OWASPとは

OWASP（Open Worldwide Application Security Project）は非営利のコミュニティであり、セキュリティに関する啓発活動を行っています。

OWASP Top 10とは

Webアプリケーションにおける重大なセキュリティリスクを10項目にまとめ、定期的に更新されるセキュリティレポートです。開発者や設計者がセキュリティ対策を進める上で、広く参照されています。現在の最新版は2025年に発表されており、その前は2021年の発表でした。アップデートから日が浅いため、2025年版の内容に対応した診断ツールはまだ少ないかもしれません。

OWASP Top 10 2021からの変更点

2021 vs 2025

2025年版ではSoftware Supply Chain FailuresとMishandling of Exceptional Conditionsの2つのカテゴリが新設され、2021 A10:Server-Side Request ForgeryはA01:2025 Broken Access Controlのカテゴリに統合されています。

Software Supply Chain Failuresは、2021 A06: Vulnerable and Outdated Componentsを拡張したカテゴリであり、既知の脆弱性を持つライブラリやOSSの利用だけでなく、開発環境やCI/CDパイプラインなど、ソフトウェアの開発から配布までの一連のプロセスに関わるリスクを対象としています。Mishandling of Exceptional Conditionsは、エラー処理やフェイルオープンなど、異常時の不適切な対応に関するリスクを扱うカテゴリであり、これまではコード品質の問題とされていた領域がセキュリティリスクとして整理されています。

症状（Symptoms）よりも根本原因（Root Cause）を重視する方針が示されており、どのような脆弱性があるかだけではなく、問題がなぜ発生するのかを意識した構成となっています。

OWASP Top 10 2025のカテゴリ

A01: Broken Access Control

アクセス制御の不備によって、本来アクセスできない情報や機能にアクセスできてしまう問題です。情報漏洩や権限昇格など重大なインシデントに繋がるため、OWASP Top 10では2021年版から引き続き、首位に位置付けられています。

具体例

URLやリクエストパラメータ内のユーザーIDを変更するだけで、他ユーザーの情報を閲覧できる
一般ユーザーが、本来は管理者のみ利用できる機能や画面へアクセスできる
本来アクセス権のないファイルやデータを取得できる

予防法

サーバー側でアクセス権限をチェックする
管理者機能は一般ユーザーから利用できないよう制御する
ファイルやデータごとにアクセス権を適切に設定する

A02: Security Misconfiguration

2021年版からは3ランクアップしました。システムやミドルウェア、クラウドサービスなどの設定が適切に行われていないことで発生するリスクです。クラウドやSaaSの活用が進んだことで設定項目も増えており、高度な攻撃だけでなく、単純な設定ミスが思わぬインシデントにつながるケースもあります。

具体例

本番環境でデバッグ機能が有効
初期アカウントやデフォルトパスワードが変更されていない
クラウドストレージや管理画面が誤った設定により公開されている

予防法

本番環境ではデバッグ機能を無効化する
初期アカウントやデフォルトパスワードを変更する
クラウドサービスや管理画面の公開設定を定期的に確認する

A03: Software Supply Chain Failures

2021年版からは3ランクアップしました。アプリケーション本体だけでなく、利用しているライブラリやOSS、パッケージ、CI/CDパイプラインなど、ソフトウェアサプライチェーン全体に起因するリスクです。自分たちが開発したコードだけでなく、システムを構成する部品全体にも目を向ける必要があります。

具体例

脆弱性が公表されているライブラリを使い続けている
メンテナンスが終了したOSSを利用している
CI/CDパイプラインへの不正なコード混入

予防法

利用しているライブラリやOSSを継続的に更新する
サポート終了したコンポーネントの利用を避ける
CI/CDパイプラインへのアクセス権を適切に管理する

A04: Cryptographic Failures

2021年版からは2ランクダウンしました。機密情報を守る上で暗号化は欠かせない仕組みですが、古い暗号方式の利用や不適切な実装、鍵管理の不備があると、その効果を十分に発揮できません。一度導入したら終わりではなく、利用している暗号方式や鍵管理の方法を定期的に見直していくことも大切だと思います。

具体例

パスワードを平文で保存
古い暗号アルゴリズムを使用
通信がHTTPSではなくHTTPで行われている

予防法

パスワードは適切なハッシュ化方式で保存する
推奨されている暗号アルゴリズムを利用する
通信はHTTPSを利用し暗号化する

A05: Injection

2021年版からは2ランクダウンしました。ユーザーから入力されたデータを適切に検証せずに処理することで、不正な命令を実行されてしまう問題です。SQL Injectionに代表される古くから知られた脆弱性ですが、現在でも独自実装や設定不備によって発生するケースがあるため、注意が必要です。

具体例

SQL Injectionによってデータベース内の情報を取得される
検索機能やAPIへの入力値を改ざんし、本来参照できないデータを取得される
OSコマンドを不正に実行される

予防法

SQL文やコマンドへユーザー入力を直接連結しない
入力値の検証を実施する
パラメータ化クエリやORMを利用する

A06: Insecure Design

2021年版からは2ランクダウンしました。設計段階でセキュリティが十分に考慮されていないことによって発生する問題です。実装上の不具合というよりも、設計時の考慮不足によって生じるものであり、「後から修正する」のではなく、「最初から考えておく」ことの重要性を示しているカテゴリだと感じました。

具体例

パスワードリセット機能に十分な本人確認がなく、他人のアカウントを乗っ取れてしまう
システムの利用ルールに不備があり、本来想定していない操作ができてしまう
Botや大量アクセスによる不正利用を防ぐ仕組みが設計されていない

予防法

パスワードリセット機能には十分な本人確認を設ける
利用ルールや業務ロジックを設計段階で整理する
Bot対策や利用制限をあらかじめ設計へ組み込む

A07: Authentication Failures

2021年版から変動はありません。認証やセッション管理に関する不備によって発生するリスクです。認証情報の漏洩や不正ログイン、なりすましにつながる可能性があります。近年では、証券会社などでも不正ログイン対策として多要素認証（MFA）の導入が進められています。利用者の立場では少し面倒に感じることもありますが、こうした仕組みが導入される背景には実際の脅威があることを考えると、認証機能はセキュリティ対策の基盤となる重要な要素だと感じます。

具体例

簡単に推測できるパスワードを許可している
MFA（多要素認証）が未導入
ログアウト後もセッションが有効なままになっている

予防法

推測されやすいパスワードを禁止する
多要素認証（MFA）を導入する
ログアウト時にセッションを確実に無効化する

A08: Integrity Failures

2021年版から変動はありません。ソフトウェアやデータの完全性が保証されていないことによって発生するリスクです。改ざんされたコードやデータを信頼してしまうことで、システムの信頼性や安全性が損なわれる可能性があります。そのため、コードやデータが意図しない形で変更されていないことを確認する必要があります。

具体例

信頼できない配布元から取得したパッケージやライブラリを利用してしまう
ソフトウェアアップデートの正当性を確認せずに適用してしまう
改ざんされたデータを正しいものとして処理してしまう

予防法

信頼できる配布元からのみソフトウェアを取得する
ソフトウェアアップデートの署名や正当性を確認する
データの改ざんを検知する仕組みを導入する

A09: Logging & Alerting Failures

2021年版から変動はありません。ログ取得や監視体制が不十分であることによって、攻撃や異常を検知できない問題です。セキュリティ対策というと防ぐことに目が向きがちですが、異常に気付ける状態を作っておくことも同じくらい大切なのだと思います。過去の案件では、例外処理が多用された結果、ログが大量に出力され、本当に確認すべき異常が埋もれてしまっていたことがありました。ログを残すだけでなく、必要な情報を適切に把握できる状態にしておくことも必要です。

具体例