Webアプリケーションの脆弱性とは？種類一覧（OWASP Top 10:2025）と対策・診断方法

Webアプリケーションの脆弱性とは、設計や実装の不備によって生じる、攻撃者に悪用されうる弱点のことです。悪用されると、個人情報の漏えいやサイトの改ざん、サービスの停止につながります。近年も、Webサイトへの不正アクセスによる個人情報の漏えいが相次いで報じられています。

本記事では、Webアプリケーションの脆弱性の代表的な種類を、国際的な指標であるOWASP Top 10の最新版（2025年版）に沿って整理し、それぞれの対策を解説します。あわせて、個人情報が漏えいした場合に企業が負う報告義務と、自社のアプリに脆弱性があるかを確かめる方法（脆弱性診断）も紹介します。

Webアプリケーションの脆弱性は、プログラムの書き方だけでなく、設計や設定、利用している部品など、さまざまなところから生まれます。まずは、脆弱性が生まれる原因と、放置した場合に起きることを整理します。

脆弱性が生まれる5つの原因

1. 設計時の考慮漏れ：誰がどのデータを見てよいか、といった決め事が設計の段階で抜けている
2. 実装のミス：入力値のチェック漏れや、画面に出力するときのエスケープ忘れ
3. ライブラリ・フレームワークの放置：古いバージョンを使い続け、公表済みの脆弱性が残っている
4. 設定の不備：初期パスワードのまま、デバッグ機能が本番環境で有効になっている、など
5. 新しい攻撃手法の登場：作った時点では安全でも、後から見つかった手口で突かれる

脆弱性を完全になくすことは難しいため、作る段階で減らすことと、定期的に確かめることの両方が必要です。

脆弱性を放置すると何が起きるか

脆弱性を突かれた場合に企業が受ける影響は、主に次の3つです。

• 情報の漏えい：顧客の個人情報やクレジットカード情報、社内の機密情報が外部に流出する
• サイトの改ざん・停止：Webサイトの内容を書き換えられる、不正なプログラムを仕込まれる、サービスを止められる
• 信頼の低下と対応の負担：顧客や取引先からの信頼を失うだけでなく、原因の調査、関係機関への報告、本人への連絡といった対応に追われる

特に個人情報の漏えいについては、法律で報告の義務と期限が定められています（後述）。

OWASP（Open Worldwide Application Security Project）は、Webアプリケーションのセキュリティ向上に取り組む国際的な非営利団体です。同団体が数年ごとに公表する「OWASP Top 10」は、Webアプリケーションの重大なリスクを10項目に整理したもので、脆弱性診断や開発基準の目安として広く使われています。最新版は2025年版です。

出典：OWASP Top 10:2025（日本語版）　※分類名は公式の日本語名称。「どんな弱点か」「主な対策」は当社による要約です。

ここからは、Webアプリケーションで特に見つかりやすい5つの分類を詳しく解説します。

アクセス制御の不備

2021年版に続いて1位に挙げられている分類です。ログインしている利用者が、自分の権限では見られないはずのデータや機能に到達できてしまう状態を指します。代表的な例は次のとおりです。

• パラメータの改ざん：URLやフォームの値（会員番号や注文番号など）を書き換えて、他人の情報を表示させる
• 強制ブラウジング：管理画面など、リンクの無いページのURLを直接入力して開く
• ディレクトリトラバーサル：「../」などの文字列でファイルの場所を書き換え、公開していないファイルを読み出す

対策の基本は、画面を表示するたび、処理を実行するたびに「この利用者に権限があるか」をサーバー側で確かめることです。画面からリンクを消すだけでは防げません。あわせて、入力されたファイルパスを正規化して想定外の場所を指していないか確かめる、公開しないファイルはWebから届く場所に置かない、といった対策も有効です。

この分類の脆弱性は、「誰に何を見せてよいか」という仕様を知らないと判断できないため、自動ツールだけでは見つけにくいという特徴があります。

セキュリティ設定の不備

アプリケーションのコードに問題がなくても、サーバーやミドルウェア、CMSの設定に不備があると攻撃の入口になります。よくある例は次のとおりです。

• 管理画面や機器の初期パスワードを変えていない
• 使っていない機能やサンプルページが有効なまま残っている
• エラー画面にデータベースの種類やプログラムの内部情報が表示される
• 開発時に使うデバッグ機能が、本番環境でも有効になっている
• ディレクトリの一覧表示が有効で、ファイルの一覧が外から見える

対策としては、本番環境向けの設定基準を決めて構築時に適用し、その後も定期的に点検することが有効です。特にデバッグ機能は、開発中に便利な一方で内部の情報を外に出してしまうため、本番環境では必ず無効にします。

ソフトウェアサプライチェーンの不備

2025年版で新たな名称で加わった分類です。今のWebアプリケーションは、外部のライブラリやフレームワークを数多く組み合わせて作られています。自社で書いたコードに問題がなくても、使っている部品に脆弱性があれば、そこから攻撃を受けます。古いライブラリの放置に加え、部品を取り込んだり配布したりする過程での改ざんも、この分類に含まれます。

対策は、どの部品のどのバージョンを使っているかを一覧で把握し、公表された脆弱性が見つかったら速やかに更新することです。この確認は、SCA（ソフトウェア構成分析）と呼ばれるツールで自動化できます。

インジェクション（SQLインジェクション・XSS・OSコマンドインジェクション）

インジェクションは、利用者が入力した値が、データベースやブラウザ、OSへの命令として実行されてしまう脆弱性です。代表的なものを3つ紹介します。

SQLインジェクション

攻撃者が不正なSQL文をデータベースに送り、情報を盗んだり改ざんしたりする攻撃です。入力値をそのままSQL文に組み込んでいると、意図しないSQL文が実行されます。また、エラーメッセージからデータベースの構造を推測され、攻撃の足がかりにされることもあります。

• SQL文のパラメータ化：プレースホルダを使ってSQL文を組み立て、入力値が命令として解釈されないようにする
• 入力値の検証：想定した形式・長さの値だけを受け付ける
• エラーメッセージの工夫：データベースの詳細が推測されないよう、利用者に見せる内容を絞る

クロスサイトスクリプティング（XSS）

攻撃者が悪意のあるスクリプトをWebページに埋め込み、そのページを閲覧した利用者のブラウザで実行させる攻撃です。個人情報を盗まれたり、ログイン状態を乗っ取られたりするおそれがあります。手口によって、次の3種類に分けられます。

• 反射型XSS：悪意のあるスクリプトを含むURLを踏ませ、そのページを開いたときに実行させる
• 格納型XSS：掲示板などにスクリプトを保存し、そのページを開いた人のブラウザで実行させる
• DOMベースXSS：ページ内のJavaScriptの処理を悪用し、ブラウザ上でスクリプトを実行させる

対策としては、画面に出力する値を必ずエスケープすること、Content Security Policy（CSP）で実行してよいスクリプトを制限すること、WAF（Webアプリケーションファイアウォール）で攻撃を検出・遮断することが挙げられます。

OSコマンドインジェクション

Webアプリケーションがサーバー上でOSのコマンドを呼び出している場合に、入力値にコマンドを紛れ込ませて実行させる攻撃です。情報の漏えいやファイルの改ざん・削除、マルウェアへの感染、他のサイトを攻撃するための踏み台化につながります。

最も確実な対策は、アプリケーションからOSコマンドを呼び出さない設計にすることです。やむを得ず呼び出す場合は、入力値を厳しく検証し、コマンドとして特別な意味を持つ文字を無害化します。

認証の不備（セッション管理・Cookie）

ログインの仕組みやログイン後の状態管理に不備があると、攻撃者が他人になりすませてしまいます。パスワードの総当たりや、他のサイトから流出したIDとパスワードの使い回しを狙う攻撃に加え、ログイン状態を示すCookieを盗んだり書き換えたりする手口もあります。

• 多要素認証：パスワードに加えて、別の要素での確認を求める
• ログイン試行回数の制限：短時間に何度も失敗した場合はロックする
• セッションIDの適切な管理：推測されにくい値を使い、ログイン時に新しい値へ切り替える
• HttpOnly属性：JavaScriptからCookieを読み取れないようにし、XSSによる窃取を防ぐ
• Secure属性：CookieをHTTPS通信でのみ送るようにし、通信の途中での漏えいを防ぐ

2022年4月に施行された改正個人情報保護法により、一定の個人データの漏えいが起きた場合（起きたおそれがある場合を含む）、企業は個人情報保護委員会への報告と、本人への通知が義務になりました。

報告が必要になる4つのケース

1. 要配慮個人情報（病歴など）が含まれる
2. 財産的な被害が生じるおそれがある（クレジットカード番号、決済機能のあるサービスのIDとパスワードなど）
3. 不正の目的をもって行われたおそれがある（第三者による不正アクセスなど）
4. 本人の数が1,000人を超える

Webアプリケーションの脆弱性を突いた不正アクセスによって個人データが漏えいした場合は、3つめのケースに当たります。この場合は、漏えいした件数が少なくても報告の対象になります。

報告の期限

• 速報：漏えいに気づいてから3〜5日以内
• 確報：30日以内（不正の目的によるおそれがある場合は60日以内）

脆弱性の放置は、情報が漏れるだけの問題ではありません。短い期限の中で原因を調べ、報告し、本人に知らせるという対応の負担も生じます。

出典：個人情報保護委員会「漏えい等の対応」

脆弱性は、後から見つけて直すよりも、作る段階で生まないほうが手戻りが少なく済みます。開発の段階では、次の5点を押さえておきます。

1. 入力を信用しない：利用者からの入力は、形式・長さ・範囲を必ず確かめる
2. 出力時にエスケープする：画面やSQL文、コマンドに値を渡すときは、その出力先に合った方法で無害化する
3. 権限は最小限にする：利用者やプログラムに与える権限は、必要な範囲に絞る
4. 部品を把握して更新する：使っているライブラリやフレームワークのバージョンを管理し、更新を後回しにしない
5. 設計の段階でレビューする：画面や機能を作る前に、「誰が何をできるか」「どう悪用されうるか」を確かめる

開発者向けのセキュリティ対策は、Webアプリケーションセキュリティの重要性と完全ガイドでも詳しく解説しています。

どれだけ注意して作っても、脆弱性をゼロにすることは困難です。そこで、自社のWebアプリケーションに脆弱性がないかを確かめる「脆弱性診断」が必要になります。

診断の種類

ツールだけでは見つけにくいもの

自動ツールは、SQLインジェクションのように型の決まった脆弱性を見つけるのが得意です。一方で、OWASP Top 10で1位の「アクセス制御の不備」や「安全性を欠いた設計」は、「誰に何を見せてよいか」という仕様を知らないと判断できません。ツールの結果を専門家が確認し、仕様に照らして評価することが欠かせません。

診断から改修までの進め方は、ECサイトリニューアルで発覚した脆弱性―開発チームと連携した診断・改修の全記録で実例を紹介しています。

内製か委託か

脆弱性診断は「診断する」という一つの作業ではなく、対象の棚卸しから再診断までいくつもの工程に分かれます。どこまでを自社で行い、どこからを外部に任せるかの考え方は、脆弱性診断は内製か委託か｜二択で決める前に整理すべき「6つの工程」をご覧ください。

Webアプリケーションの脆弱性は、OWASP Top 10:2025に沿って見ると、アクセス制御・設定・サプライチェーンといった「コードの書き方以外」の原因が上位を占めています。開発段階の対策に加えて、定期的な診断で確かめることが、漏えいとその後の報告対応を防ぐ近道です。

コウェルのWebアプリケーション脆弱性診断は、DAST・SCA・IASTをお客様の環境に合わせて組み合わせ、専任エンジニアが結果を精査します。脆弱性を見つけるだけでなく、改修の支援までまとめてご相談いただけます。生成AIを組み込んだアプリケーションには、LLM脆弱性診断もご用意しています。

実際の診断レポートの内容は、脆弱性診断サンプルレポートでご確認いただけます。