自社のWebサイトやWebアプリケーションに脆弱性診断を実施する——そう決まったとき、「診断では具体的に何を調べてもらえるのか」を知っておきたい場面は少なくありません。見積もりを取る前や、社内で説明する前に把握しておきたい情報です。診断項目の中身が分からないままでは、自社サイトのどの機能が対象になるのか、返ってくる報告書をどう改修に活かせるのかを判断しづらいからです。
脆弱性診断は、攻撃者に悪用されうる弱点を公開前や運用中に洗い出すための検査です。ただ、ひとくちに「診断」といっても、調べる項目は入力値の処理から認証・認可、セッション管理、サーバの設定まで幅広く、どこまでを対象にするか（診断範囲）や報告書の形もサービスによって異なります。
この記事では、Webサイトの脆弱性診断で実際にチェックされる診断項目を、分類ごとに一覧で示します。あわせて、OWASP Top 10 や IPA（独立行政法人情報処理推進機構）のウェブ健康診断仕様といった公式基準との対応、診断範囲の決め方、報告書に載る内容までを整理します。
目次
一括ダウンロードする
Webサイト脆弱性診断の「診断内容」とは
Webサイトの脆弱性診断の「診断内容」とは、攻撃者に悪用されうる既知の弱点がないかを、攻撃者と同じ視点で検査することを指します。検査の対象は、入出力処理・認証・認可・セッション管理・サーバや設定といった複数の分類にわたります。
特定の1種類の弱点だけを見るわけではありません。Webアプリケーションが外部からの入力を受け取り、利用者を認証し、権限に応じて処理を実行し、結果を返すという一連の流れのどこに弱点が生じうるかを、項目ごとに確認していきます。
公的な位置づけとしては、IPA が公開する「ウェブ健康診断仕様」が、基本的な診断の考え方を次のように説明しています。
「ウェブ健康診断」とは、ウェブサイトを人間に例えるなら、その名のとおり 「健康診断」にあたるような位置づけの診断です。
ウェブ健康診断は「基本的な対策が出来ているかどうかを診断するもの」とご理解ください。また、診断対象のウェブアプリケーションの全てのページを診断するものではなく、診断対象の規模にもよりますが、基本は抜き取り調査（診断）です。
出典：安全なウェブサイトの作り方 別冊「ウェブ健康診断仕様」｜独立行政法人情報処理推進機構（IPA）
このように診断内容は、サイトのすべてを無制限に調べるものではなく、「どの項目を」「どの範囲で」検査するかを決めたうえで実施されます。ここからは、まず実際に検査される診断項目を分類ごとに見ていきます。
Webサイト脆弱性診断の診断項目一覧【分類別】
ここからは、Webサイトの脆弱性診断で検査される項目を、弱点が生じる箇所ごとに5つの分類（入出力処理／認証／認可／セッション管理／サーバ・設定）に分けて一覧で示します。各項目について、どんな攻撃を受け、何が起きるのかを合わせて整理します。
入出力処理の脆弱性
利用者からの入力を処理し、画面やデータベース、外部システムへ出力する過程で生じる弱点です。Webアプリケーションの脆弱性の中でも代表的で、影響が大きいものが多く含まれます。
| 診断項目 | どんな攻撃を受け、何が起きるか |
|---|---|
| SQLインジェクション | 入力値をもとに組み立てるSQL文（データベースへの命令文）の不備を突かれ、非公開情報の閲覧、データの改ざん・消去、認証回避による不正ログインなどにつながる |
| クロスサイト・スクリプティング（XSS） | ページ出力の不備により不正なスクリプトを埋め込まれ、閲覧した利用者のCookie（セッションID）の窃取・なりすまし、偽ページの表示につながる |
| OSコマンド・インジェクション | 入力値を通じてサーバのOSコマンドを実行され、システムの乗っ取りや、他者への攻撃の踏み台として悪用される |
| CSRF（クロスサイト・リクエスト・フォージェリ） | ログイン中の利用者に、送金・退会・パスワードや設定の変更など取り消しできない処理を、気づかぬうちに実行させられる |
| ディレクトリ・トラバーサル（パス名パラメータの未チェック） | ファイル名の指定の不備を突かれ、公開を想定していないサーバ内のファイルを閲覧・取得される |
| HTTPヘッダ・インジェクション／メールヘッダ・インジェクション | 改行コードの扱いの不備を突かれ、不正なHTTPヘッダの挿入や、意図しない宛先へのメール送信に悪用される |
| 意図しないリダイレクト（オープンリダイレクト） | リダイレクト先の検証不足を突かれ、利用者を悪意あるサイトへ誘導される |
たとえばSQLインジェクションについて、IPA は発生しうる脅威として「データベースに蓄積された非公開情報の閲覧（個人情報の漏えい 等）」「認証回避による不正ログイン」などを挙げています。入力値の処理の不備が、情報漏えいからシステムの乗っ取りまで広い被害につながりうる点が特徴です。
CSRF（クロスサイト・リクエスト・フォージェリ）は、この表では入出力処理に含めています。ただし送信元の正当性の検証不足に起因するため、OWASP Top 10 2021 ではアクセス制御（A01）に分類されます（後述の公式基準との対応を参照）。
出典・参考資料（2件）
認証の脆弱性
利用者が本人であることを確認するログイン処理まわりの弱点です。ここを突かれると、正規の利用者になりすまされます。
| 診断項目 | どんな攻撃を受け、何が起きるか |
|---|---|
| 認証の回避 | ログイン処理の実装の不備により、正規の認証情報なしにログインされる |
| 推測可能なパスワード・脆弱なパスワードポリシー | 単純なパスワードが許容され、総当たりや推測でアカウントを奪取される |
| アカウントロックの不備 | 連続した認証失敗を制限しておらず、総当たり攻撃を許してしまう |
認可（アクセス制御）の脆弱性
認証を通過した利用者が、自分に許可された範囲だけを操作できているか——権限の制御に関する弱点です。IPA の用語では「認可制御」にあたります。
| 診断項目 | どんな攻撃を受け、何が起きるか |
|---|---|
| 権限昇格 | 一般利用者が、管理者権限など本来持たない権限を取得して操作する |
| 強制ブラウジング | 権限がないと想定されるURLに直接アクセスし、非公開のページや機能を利用される |
| 他者データの参照（IDOR） | リクエスト中のIDなどを書き換え、他の利用者のデータを閲覧・操作される |
セッション管理の脆弱性
ログイン状態を保持するためのセッションの扱いに関する弱点です。セッションIDが固定・推測・窃取されると、利用者へのなりすましにつながります。
| 診断項目 | どんな攻撃を受け、何が起きるか |
|---|---|
| セッションIDの固定化（セッション・フィクセーション） | 攻撃者が用意したセッションIDを利用者に使わせ、ログイン後になりすます |
| セッションIDの推測・窃取（セッションハイジャック） | 推測可能、または窃取されたセッションIDで利用者になりすます |
| Cookieの属性不備 | Secure属性やHttpOnly属性の欠如により、Cookieが盗聴・窃取されやすくなる |
サーバ・設定の脆弱性
アプリケーションのコードそのものではなく、サーバや各種ソフトウェアの設定・構成に起因する弱点です。Webサイトが動く土台の側の問題で、設定の見直しや更新で対処できるものが多く含まれます。
| 診断項目 | どんな攻撃を受け、何が起きるか |
|---|---|
| セキュリティ設定の不備 | 不要な機能やデフォルト設定が残り、攻撃の糸口になる |
| ディレクトリ・リスティング | ディレクトリ内のファイル一覧が閲覧可能になり、非公開ファイルの存在が露呈する |
| 既知の脆弱なミドルウェア・古いコンポーネント | サーバOS・ライブラリ・CMS（WordPress等）に残る既知の脆弱性を突かれる |
| TLS（通信の暗号化）設定の不備 | 通信の暗号化設定が不十分で、盗聴や改ざんのリスクが残る |
公式基準（OWASP Top 10 / IPA ウェブ健康診断仕様）との対応
ここまでの診断項目は、公的・国際的な基準に対応しています。代表的なのが、OWASP（Open Worldwide Application Security Project）が公開する「OWASP Top 10」と、IPA の「ウェブ健康診断仕様」です。
IPA のウェブ健康診断仕様は、Webサイトの基本的な診断項目を記号（A）〜（M）の13項目として定義し、各項目に危険度（高／中／低）を示しています。一方 OWASP Top 10 は、Webアプリケーションのセキュリティリスクを10カテゴリに整理した国際的な基準です。
次の表は、本記事の診断項目一覧で挙げた項目を、分類ごとにこの2つの公式基準へ対応づけたものです。
| 分類 | 診断項目 | IPA ウェブ健康診断仕様（記号・危険度） | OWASP Top 10 2021 |
|---|---|---|---|
| 入出力処理 | SQLインジェクション | （A）／高 | A03 Injection |
| 入出力処理 | クロスサイト・スクリプティング（XSS） | （B）／中 | A03 Injection |
| 入出力処理 | OSコマンド・インジェクション | （D）／高 | A03 Injection |
| 入出力処理 | CSRF | （C）／中 | A01 Broken Access Control |
| 入出力処理 | ディレクトリ・トラバーサル | （G）／高 | A01 Broken Access Control |
| 入出力処理 | HTTPヘッダ・インジェクション／メールヘッダ・インジェクション | （I）／（F）／中 | A03 Injection |
| 入出力処理 | 意図しないリダイレクト | （H）／中 | A01 Broken Access Control |
| 認証 | 認証の回避・推測可能なパスワード・アカウントロックの不備 | （J）／低〜中 | A07 Identification and Authentication Failures |
| 認可（アクセス制御） | 権限昇格・強制ブラウジング・他者データの参照（IDOR） | （L）／高 | A01 Broken Access Control |
| セッション管理 | セッションIDの固定化・推測・Cookieの属性不備 | （K）／低〜高 | A07 Identification and Authentication Failures |
| サーバ・設定 | セキュリティ設定の不備・ディレクトリ・リスティング | （E）／低〜高 | A05 Security Misconfiguration |
| サーバ・設定 | 既知の脆弱なミドルウェア・古いコンポーネント | ー（13項目対象外） | A06 Vulnerable and Outdated Components |
| サーバ・設定 | TLS設定の不備 | ー（13項目対象外） | A02 Cryptographic Failures |
OWASP Top 10 2021 の各カテゴリに対応する CWE（脆弱性の種類の識別子）をもとに対応づけ。「ー」は IPA ウェブ健康診断仕様の13項目に直接対応しない項目。同仕様はこのほか「クローラへの耐性」（記号M、サイトの可用性に関する項目）も定義していますが、本記事の診断項目一覧では扱っていません。
対応づけで注意したい点が2つあります。1つは、XSS と CSRF の位置づけです。XSS は 2017年版までは独立したカテゴリでしたが、OWASP Top 10 2021 では「A03 Injection」に統合されています。CSRF も 2021年版では「A01 Broken Access Control」に含まれており、いずれも版によって扱いが変わっている点は押さえておきましょう。
もう1つは基準の版です。OWASP Top 10 は2025年に最新版（2025年版）が公開され、現在はこれが現行版となっています。本記事では、IPA ウェブ健康診断仕様の診断項目と対応づけやすく、国内の診断の現場でも広く参照されている2021年版を基準に整理しています。
2025年版ではカテゴリの構成が見直され、たとえばインジェクションが A03 から A05 へ移動するなど、カテゴリ番号が2021年版と異なります。最新版も合わせて確認する場合は、OWASP の公式ページを参照してください。
出典・参考資料（3件）
診断範囲の決め方（何を・どこまで診るか）
ここからは、診断項目を「どの範囲まで」診るかの決め方を見ていきます。診断範囲は見積もりの金額や期間を左右する要素であり、社内で診断を説明・稟議する際の土台にもなります。
範囲を数える単位（画面・機能・リクエスト・APIエンドポイント）
診断範囲は、サイトの「ページ数」そのものよりも、入力や処理が発生する「画面（機能）」や、そこで送受信される動的なリクエストの数で数えるのが一般的です。
IPA のウェブ健康診断仕様も、診断対象をログイン・パスワード変更・データベース更新などの機能の単位で定義しています。クローラによる診断の対象ページ数は、最小1ページから最大4,800ページの範囲と規定されています。範囲を数える際は、こうした「機能・画面の単位」で捉えると見積もりの前提がそろいます。
実際の見積もりでは、診断会社によって「画面数」「フォーム数」「動的なリクエスト数」「APIのエンドポイント数」など数える単位が異なります。自社サイトのどの機能を対象にするかを先に整理しておくと、各社の見積もり条件を比較しやすくなります。
出典・参考資料（1件）
ログイン後の画面・会員機能・決済の扱い
会員登録・ログイン・マイページ・決済・管理画面といったログイン後の機能は、個人情報や金銭を扱うため優先して診断したい対象です。これらを診断するには、テスト用のアカウントや権限の異なる複数のアカウントを用意し、診断側に共有する準備が必要になります。範囲を決める段階で、認証後の画面をどこまで含めるかを明確にしておくと、後の工程がスムーズです。
範囲を絞る・広げる判断軸
予算やスケジュールの制約があるなかで、どこから診断するかを決める判断軸は、次の観点で整理できます。
- 公開範囲：インターネットに公開され、誰でもアクセスできる機能から優先する
- 重要データの有無：個人情報・認証情報・決済情報を扱う機能を優先する
- 外部連携：APIや外部サービスと接続する部分は、影響範囲が広がりやすいため対象に含める
- 改修・リリースのタイミング：新規公開前や大規模改修の直後は、変更箇所を中心に範囲を広げる
ツール診断と手動診断で診られる項目の違い
脆弱性診断には、ツールによる自動診断と、技術者による手動診断があります。どちらを選ぶかで、診断できる項目の深さが変わります。自社に必要な診断の深さを判断するために、両者の検出特性を整理します。
ツール診断と手動診断の検出特性の違い
| 観点 | ツール（自動）診断 | 手動診断 |
|---|---|---|
| 速度・コスト | 広い範囲を短時間・低コストで検査できる | 時間とコストがかかる |
| 得意な項目 | SQLインジェクション・XSSなど、既知のパターンを機械的に検出しやすい項目 | 認可・業務ロジック・CSRFなど、文脈の理解が必要な項目 |
| 精度 | 検出漏れや誤検知が起こりうる | 画面の流れや権限を踏まえて検証でき、精度が高い |
IPA も、検査パターンを絞り込んだ簡易な診断の限界について、次のように述べています。
「ウェブ健康診断仕様」で脆弱性が検出されなかった場合でも、検査パターンを絞り込んでいることから、安全宣言には繋がりません。
出典：安全なウェブサイトの作り方 別冊「ウェブ健康診断仕様」｜独立行政法人情報処理推進機構（IPA）
手動診断が必要になる項目とその理由
認可制御の不備やCSRFのような項目は、「誰がどの権限でログインしているか」「その処理が利用者にとって重要で取り消せないものか」といった文脈を理解したうえでなければ、本当に問題かどうかを判断できません。たとえば認可の検査は、権限のない利用者が本来アクセスできないページを開けてしまわないかを、ログイン状態を変えながら確かめる必要があります。
こうした文脈依存の項目は自動ツールだけでは見落としやすく、技術者による手動診断が有効です。自社サイトに重要な会員機能や決済がある場合は、ツール診断に手動診断を組み合わせる構成が選択肢になります。
診断報告書に載る内容
診断を実施すると、結果は報告書としてまとまります。報告書が社内の改修にどうつながるかをイメージできるよう、全体の構成から個別の脆弱性の記載内容まで順に見ていきます。
経営層向けの要約と技術者向けの詳細の2層構成
多くの診断報告書は、全体像を把握するための要約（サマリー）と、実際に改修を行う担当者向けの詳細という2層で構成されます。要約は検出された脆弱性の件数や深刻度の分布、総合的な評価をまとめたもので、経営層や責任者が状況を把握し、対応の優先順位を判断する材料になります。詳細は脆弱性ごとの技術的な情報で、開発・運用の担当者が修正に着手するために使います。
深刻度区分（Critical／High／Medium／Low）とCVSSの読み方
検出された脆弱性には、対応の優先順位を判断するための深刻度が付けられます。深刻度の客観的な指標として広く使われているのが、CVSS（共通脆弱性評価システム）です。CVSS v3.1 では、スコアに応じて次の5段階の深刻度が定義されています。
None: 0.0／Low: 0.1 – 3.9／Medium: 4.0 – 6.9／High: 7.0 – 8.9／Critical: 9.0 – 10.0
出典：Common Vulnerability Scoring System v3.1: Specification Document｜FIRST.org
日本語の報告書では、IPA や JVN（脆弱性対策情報ポータルサイト）が用いる区分で示されることもあります。具体的には「緊急（9.0〜10.0）／重要（7.0〜8.9）／警告（4.0〜6.9）／注意（0.1〜3.9）／なし（0）」です。英語表記でも日本語表記でも、スコアの範囲は同じです。また、CVSS の最新版は v4.0 ですが、深刻度の5段階の考え方は共通しています。
また、先に触れた IPA ウェブ健康診断仕様の危険度（高／中／低の3段階）は CVSS とは別の体系なので、報告書を読む際は混同しないよう注意してください。
出典・参考資料（2件）
脆弱性ごとの該当箇所・再現手順・想定被害
詳細部分では、検出された脆弱性ごとに、どのURLやパラメータで見つかったか（該当箇所）、どうすれば再現できるか（再現手順）、放置した場合に何が起こりうるか（想定被害）が記載されます。再現手順が具体的に示されていると、開発担当者が問題を確認しながら修正でき、対応がスムーズになります。報告書を選ぶ際は、この詳細の具体性も確認したいポイントです。
対策案
検出された脆弱性に対して、どう修正すればよいかの対策案が示されます。対策が具体的であるほど、改修の計画が立てやすくなります。
たとえば、SQLインジェクションならプレースホルダ（プリペアドステートメント）を使う、クロスサイトスクリプティングなら出力時にエスケープ処理を施す、セッション管理の不備ならログイン後にセッションIDを再発行する、といった具合に、脆弱性の種類ごとに修正の方向性が示されるのが一般的です。
すべての脆弱性を同じ優先度で直す必要はなく、深刻度に応じて優先順位をつけ、修正が難しいものは暫定的な対策を含めて計画に落とし込むのが現実的です。
一括ダウンロードする
脆弱性診断の継続運用とサービス活用
ここまでで、Webサイトの脆弱性診断で何を・どこまで診るのか、結果がどう返ってくるのかを整理してきました。実際には、攻撃の手口は日々更新され、サイトの改修も繰り返されるため、診断は一度きりではなく、新規公開時・改修時・定期的にと、継続して回していく必要があります。ただ、専門人材が限られる中で自社だけで継続的に診断し続けるのは負担が大きいのも事実です。
継続運用の進め方は、大きく2つの方向に分かれます。1つは、WebアプリケーションやAPIの診断を専門会社にまとめて委託し、報告書を受け取る方法です。もう1つは、ソースコードやクラウド設定、サーバOS・依存ミドルウェアまでをツールで日常的に検査し、開発・運用の中で継続的に回す方法です。ここでは、それぞれの代表的なサービスを紹介します。
| 比較項目 | CoWorker 脆弱性診断サービス | Aikido Security |
|---|---|---|
| 提供形態 | 委託型 （専門会社に診断を依頼し報告書を受領） | ツール型 （SaaSで自動スキャンを継続利用） |
| 主な診断対象 | Webアプリ・API ソースコード | ソースコード・依存ライブラリ クラウド設定・稼働中Webアプリ |
| 診断の進め方 | AIによる自動解析＋ 社内専門家の最終確認 | 管理画面での自動スキャン アラートを統一して一元管理 |
| 契約・課金形態 | 診断ごとの委託 （都度依頼） | 月額サブスクリプション （利用者数で規模が決まる） |
| 継続運用のしやすさ | 四半期・月単位での 定期依頼にも対応 | 開発・運用に組み込み 日常的に検査 |
| 参考料金 | ソースコードAI診断 150,000円〜 ソースコード＋動的診断 500,000円〜 （MCB FinTechカタログ掲載情報） | 月額5万円台〜 （MCB FinTechカタログ掲載情報） |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
1. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、WebアプリケーションやAPIを対象に、ソースコード・稼働中のアプリケーションの両面から弱点を洗い出す委託型の診断サービスです。自社開発のAI「Red Agent」による自動解析に、社内のセキュリティ専門家による最終確認を組み合わせる二段構成を特徴としています。
診断メニューは、次の3つで構成されます。
- ソースコードAI診断（ソースコードをAIが解析）
- 動的脆弱性診断（Web／API診断。稼働中のWebアプリ・APIに攻撃者視点でアクセス）
- 実践攻撃シミュレーション診断（ペネトレーションテスト。実際の攻撃を想定）
ソースコード診断単体から、動的診断・ペネトレーションテストまで段階的に選べるため、自社サイトの規模や目的に応じて範囲を決めやすいのが利点です。
MCB FinTechカタログの掲載情報では、ソースコードAI診断が150,000円、ソースコード診断と動的診断を組み合わせたプランが500,000円からと案内されています。料金は変動するため、詳細は資料や見積もりで確認してください。
攻撃側の高速化に対応し、年1回ではなく四半期や月単位での定期的な診断も実現しやすいことを打ち出しています。
なぜ診断を定期的に繰り返す必要があるのか、その背景にある攻撃側の変化について、同社は次のように説明しています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
2. Aikido Security（株式会社AndGo）
ソースコード・依存ライブラリ・クラウド設定・稼働中のWebアプリまでを1つの管理画面で検査するのが、SaaS型の診断ツール Aikido Security です。開発元はベルギーの Aikido Security BV で、日本では株式会社AndGo が販売・導入支援の窓口を担っています。診断のたびに依頼する委託型とは異なり、月額のサブスクリプションで継続的に利用する契約形態です。
ソースコード解析（SAST／SCA）、クラウド設定の検査（CSPM）、稼働中アプリの動的診断（DAST）に対応し、サーバOSやWordPressなど依存ミドルウェアに起因する脆弱性も検査対象に含みます。バラバラに出がちなアラートを統一して対応すべきものを絞り込み、修正案のプルリクエストを自動で作成する機能やエディター拡張など、開発の現場で継続的に回すための仕組みがそろっています。
MCB FinTechカタログの掲載情報では、月額5万円台から利用できるプランが案内されています（料金は為替等により変動するため、詳細は確認が必要です）。開発の初期からセキュリティを組み込む運用に向いたツールです。
診断を「作ったあとに一度だけ行う」ものから、開発の工程に組み込んで継続的に回すものへと変える考え方について、日本窓口を担う株式会社AndGoは次のように述べています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
委託型・ツール型を含めて脆弱性診断サービスを横断的に比較し、診断方法・費用相場・選び方まで見比べたい場合は、次のまとめ記事が参考になります。
まとめ
Webサイトの脆弱性診断の「診断内容」は、入出力処理・認証・認可・セッション管理・サーバや設定という分類ごとに、攻撃者に悪用されうる弱点を洗い出すものでした。各診断項目は OWASP Top 10 や IPA のウェブ健康診断仕様といった公式基準に対応しており、どの項目が診られるかを基準と照らして確認できます。
診断を依頼する際は、まず自社サイトのどの機能を対象にするか（診断範囲）を整理し、ツール診断と手動診断のどちらが必要かを見極めることが、適切な見積もりと社内説明の第一歩になります。そして報告書の深刻度区分や再現手順・対策案を手がかりに、優先順位をつけて改修を進めていきます。攻撃と改修が続く以上、診断は継続して回す前提で、委託型の診断とツールによる継続検査を自社の体制に合わせて選びましょう。
各サービスの詳細は、資料で比較して検討してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. 脆弱性診断とは何ですか？
A. 脆弱性診断とは、Webサイトやサーバに、攻撃者に悪用されうる既知の弱点（脆弱性）がないかを、攻撃者と同じ視点で検査するセキュリティテストです。入出力処理・認証・認可・セッション管理・サーバや設定といった分類ごとに診断項目を確認し、見つかった弱点を深刻度や対策案とともに報告書にまとめます。Webサイトの公開前の確認や、運用中の定期的なチェックとして実施されます。
Q. Webサイトの脆弱性診断は、どのくらいの頻度で実施すればよいですか？
A. Webサイトの脆弱性診断は、新規公開前・大規模な改修の直後・定期的に、という3つのタイミングで実施するのが基本です。定期的な診断は年1回以上を目安にし、個人情報や決済情報を扱うサイトは頻度を上げるとよいでしょう。攻撃の手口は日々更新され、サイトを改修するたびに新たな弱点が生じうるため、一度きりではなく継続して回す前提で計画します。
Q. Webサイトの脆弱性診断中は、サイトを停止する必要がありますか？
A. Webサイトの脆弱性診断では、通常サイトを停止する必要はなく、公開・運用したままリモートで実施できます。ただし診断では多数のリクエストを送信するため、サーバに一時的な負荷がかかることがあります。アクセスの少ない時間帯を選ぶ、実施時間をあらかじめ調整するなど、診断会社と相談して進めると安心です。
Q. WordPressで作ったWebサイトも脆弱性診断の対象になりますか？
A. WordPressで作ったWebサイトも脆弱性診断の対象になります。本体やテーマ・プラグインに既知の脆弱性が残っていないか、管理画面や権限の設定に不備がないかなどが診断されます。本記事の分類では「サーバ・設定の脆弱性」に含まれ、CMSなど依存するソフトウェアが古いバージョンのままだと攻撃の糸口になりやすいため、更新状況もあわせて確認されます。
WordPressサイトに絞った診断の進め方や、無料ツールで済む範囲とプロの診断が必要になる範囲の違いは、次の記事で詳しく解説しています。
Q. Webサイトの脆弱性診断で見つかった脆弱性は、すべて修正しないといけませんか？
A. すべてを一律に修正する必要はなく、深刻度（リスクレベル）に応じて優先順位をつけて対応するのが現実的です。報告書では脆弱性ごとにCriticalやHighといった深刻度が示されるため、影響の大きいものから修正します。すぐに修正が難しい項目は、アクセス制限やWAF（Webアプリケーションファイアウォール）などの暫定的な対策を含めて、改修計画に落とし込みます。
Q. Webサイトの脆弱性診断とペネトレーションテストは何が違いますか？
A. 脆弱性診断は弱点を網羅的に洗い出す検査、ペネトレーションテストは攻撃者が特定の目標に実際に侵入できるかを試す検査、という点が違います。脆弱性診断が「どんな弱点があるか」を広く確認するのに対し、ペネトレーションテストは「その弱点を突いて重要情報の窃取や権限の奪取まで到達できるか」を攻撃シナリオに沿って検証します。
まず脆弱性診断で全体を把握し、特に重要なシステムについてはペネトレーションテストで深掘りする、という使い分けが一般的です。
目的・費用・選び方の観点からの両者のより詳しい比較と使い分けは、次の記事で解説しています。
ペネトレーションテストと脆弱性診断の違いを比較｜目的・費用・選び方まで解説
セキュリティ診断の導入を検討し始めると、「ペネトレーションテスト」と「脆弱性診断」という似た言葉に出会い、どちらを頼めばよいのか迷う場面が少なくありません。名前は違っても目的が近そうに見えるため、社内や取引先に説明するときも整理に困りがちで…
Q. Webサイトの脆弱性診断は、ツール診断だけで十分ですか？
A. ツール診断だけでは不十分な場合があり、重要な会員機能や決済を持つサイトでは手動診断との組み合わせが推奨されます。ツール診断はSQLインジェクションやXSSなど既知のパターンを広く効率的に検出できますが、認可の不備・業務ロジック・CSRFのように文脈の理解が必要な項目は見落としやすいためです。
IPA（独立行政法人情報処理推進機構）も、検査パターンを絞り込んだ簡易な診断では脆弱性が検出されなくても「安全宣言には繋がらない」としています。
出典・参考資料（1件）
Q. Webサイトの脆弱性診断の費用はどのくらいかかりますか？
A. Webサイトの脆弱性診断の費用は固定ではなく、診断する機能・画面の数や、ツール診断か手動診断かによって変わります。診断範囲が広く、認証後の画面や決済など手動診断が必要な機能が多いほど費用は上がります。
各社で見積もりの単位（画面数・フォーム数・リクエスト数・APIエンドポイント数など）が異なるため、自社サイトのどの機能を対象にするかを整理したうえで複数社を比較すると、条件をそろえて検討できます。
目安として、継続利用するツール型では月額5万円台から、専門会社に委託するソースコード診断では150,000円からといった参考料金が公表されています。いずれも本記事で紹介したサービスのMCB FinTechカタログ掲載情報です。サービスを横断して料金を見比べたい場合は、下記の一括資料請求で複数サービスの資料をまとめて取り寄せられます。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、Webサイト・Webアプリの脆弱性診断サービスの最新資料を無料で一括請求できます。診断対象・料金・報告内容を見比べて、自社に合うサービスを検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
