脆弱性診断とは？サイトセキュリティ診断の種類と自分でできる点検

セキュリティ 公開 2026-10-06　/　最終確認 2026-10-06　/　サイトスカウター編集部

脆弱性診断とは、Webサイトやサーバーに、攻撃の足がかりになりうる弱点（脆弱性）がないかを調べる検査のことです。目的は「弱点の洗い出し」で、実際に侵入できるかを試すペネトレーションテストとは狙いが異なります。サイト セキュリティ 診断を考えるときは、まずこの違いを押さえると、何を頼むべきかが見えてきます。

本格的な診断は専門の事業者や有償ツールの領域ですが、運営者が自分で今日からできる最低限の点検もあります。ソフトウェアの更新、管理画面の保護、HTTPS、セキュリティヘッダー、ディレクトリの露出の5点です。これだけで防げる事故は少なくありません。

この記事では、脆弱性診断の基本、OWASP Top 10:2025の分類、診断の種類、自分でできる点検の手順、サイトスカウターのサーバー情報調査で見られる範囲と見られない範囲、外部の診断サービスを選ぶ観点、そして他人のサイトに無断で診断ツールを使ってはいけない理由を整理します。

目次
1. 脆弱性診断とは？ペネトレーションテストとの違い 2. Webサイトの主な脆弱性とOWASP Top 10:2025 3. SQLインジェクション・XSSの基本的な対策 4. 脆弱性診断の種類：ツール診断・手動診断と外部・内部 5. サイト セキュリティ 診断を自分でする：最低限の点検5項目 6. サイトスカウター /server/ で見られる範囲と見られない範囲 7. 外部の脆弱性診断サービスを選ぶときの観点 8. 他人のサイトに無断で診断ツールを使ってはいけない理由 9. 診断の次の一歩：優先順位のつけ方 よくある質問 出典・参考資料

脆弱性診断とは？ペネトレーションテストとの違い

脆弱性とは、ソフトウェアの不具合や設定の不備のうち、攻撃に悪用されうるものを指します。脆弱性診断は、対象のシステムを網羅的に調べて、そうした弱点を見つけ出す検査です。結果は「どこに・どんな弱点があり・どの程度危険か」という一覧（報告書）としてまとまるのが一般的です。

脆弱性診断とペネトレーションテストの違い

一方、ペネトレーションテストは、攻撃者と同じ視点で、見つけた弱点を実際に使って目的（情報の取得、権限の奪取など）を達成できるかを確かめる検査です。「弱点があるか」を広く調べるのが脆弱性診断、「その弱点を連鎖させると実際にどこまで侵入されるか」を深く試すのがペネトレーションテスト、という整理が一般的です。

ただし、2つの言葉の線引きは事業者や資料によって異なります。見積もりを取るときは名称ではなく、対象範囲・手法・成果物を確認してください。

  • 脆弱性診断：網羅性を重視。定期的な点検やリリース前の確認に向く
  • ペネトレーションテスト：現実的な攻撃シナリオを想定。時間と専門性が必要で、重要システムの最終確認などに向く

サイトスカウターが提供するのは、このどちらでもありません。公開情報とHTTPレスポンスから分かる範囲を確認する簡易な点検です（詳しくは後述します）。

図1　脆弱性診断とペネトレーションテスト
×　脆弱性診断×弱点を網羅的に洗い出す×結果は脆弱性の一覧×短期間で定期的に実施しやすい×リリース前の確認に向く○　ペネトレーションテスト○実際の侵入を試みる○目的達成の可否を確認○時間と専門性が必要○重要システムの最終確認に向く

Webサイトの主な脆弱性とOWASP Top 10:2025

Webサイトの脆弱性を整理するときの代表的な物差しが、OWASP（Open Worldwide Application Security Project）のOWASP Top 10です。Webアプリケーションで重大なリスクになりやすい10分類をまとめたもので、公式サイトには2025年版が掲載されています（最終確認日：2026年10月6日）。分類は次のとおりです。

  1. A01 Broken Access Control（アクセス制御の不備）：本来見えてはいけないデータや機能に、権限のない人が触れてしまう
  2. A02 Security Misconfiguration（セキュリティの設定ミス）：初期設定のまま、不要な機能の有効化、ヘッダー未設定など
  3. A03 Software Supply Chain Failures（ソフトウェアサプライチェーンの不備）：利用しているライブラリや部品、配布経路に起因する問題
  4. A04 Cryptographic Failures（暗号化の失敗）：通信や保存データの保護が不十分
  5. A05 Injection（インジェクション）：入力値が命令として解釈されてしまう。SQLインジェクションが代表例
  6. A06 Insecure Design（安全でない設計）
  7. A07 Authentication Failures（認証の不備）：ログインやセッション管理の弱点
  8. A08 Software or Data Integrity Failures（ソフトウェアやデータの完全性の不備）
  9. A09 Security Logging and Alerting Failures（ログ記録と警告の不備）：攻撃に気づけない
  10. A10 Mishandling of Exceptional Conditions（例外的な状況の不適切な処理）

なお、OWASP Top 10は版ごとに分類や順位が入れ替わります。他の記事や資料が過去の版を前提にしていることがあるため、参照するときは何年版かを確認してください。

日本語の公的資料：IPA「安全なウェブサイトの作り方」

国内では、IPA（情報処理推進機構）の「安全なウェブサイトの作り方」が基本資料です。確認時点の最新は改訂第7版（第4刷、2021年3月31日公開）で、次の7つの脆弱性を取り上げています。

  • SQLインジェクション
  • OSコマンド・インジェクション
  • パス名パラメータの未チェック／ディレクトリ・トラバーサル
  • セッション管理の不備
  • クロスサイト・スクリプティング（XSS）
  • CSRF（クロスサイト・リクエスト・フォージェリ）
  • HTTPヘッダ・インジェクション
図2　覚えておきたい主な脆弱性
アクセス制御不備他人のデータ・機能に触れられる設定ミス初期設定のまま・ヘッダー未設定インジェクション入力が命令として実行されるXSS入力が画面のスクリプトになるCSRF利用者の権限で意図しない操作認証・セッション不備ログインや本人確認の弱点古い部品更新されないCMS・ライブラリ

SQLインジェクション・XSSの基本的な対策

関連語として検索されやすい「SQLインジェクション 対策」「XSS 対策」について、運営者や開発者が最初に押さえる要点を示します。

SQLインジェクション対策：プレースホルダを使う

SQLインジェクションは、入力値がSQL文の一部として解釈され、データベースを意図しない形で操作されてしまう問題です。対策の基本は、SQL文を文字列連結で組み立てず、プレースホルダ（値の入る場所を印だけで確保し、値は後から別に渡す仕組み）を使うことです。PHPのPDOでの例です。

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute([':email' => $email]);
$rows = $stmt->fetchAll();

1行目は、PDOの既定のエミュレーションをやめ、データベース側のプレースホルダを使わせる設定です。入力値はexecute()に別に渡しており、SQL文に混ざりません。

XSS対策：出力時にエスケープする

XSS（クロスサイト・スクリプティング）は、入力された文字列が画面上でスクリプトとして動いてしまう問題です。基本は、HTMLに出力する時点で、特殊文字をエスケープすることです。PHPなら次のように書きます。

echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

エスケープは「出力する場所（HTML本文、属性、JavaScript内、URL）」ごとに方法が違うため、テンプレートエンジンの自動エスケープ機能を使うと漏れが減ります。ヘッダー側の対策としてContent-Security-Policyもありますが、これは被害を減らす補助策で、出力時のエスケープの代わりにはなりません。ヘッダーについてはセキュリティヘッダーの解説記事で扱っています。

どちらも自分のコードでの対策が必要

これらの脆弱性は、サイトの外から分かる情報だけでは判定できません。実際に入力を与えて挙動を調べるか、ソースコードをレビューする必要があります。次の章で説明する診断の種類は、この調べ方の違いです。

脆弱性診断の種類：ツール診断・手動診断と外部・内部

脆弱性診断は、調べ方と調べる場所で整理すると理解しやすくなります。

調べ方：ツール診断と手動診断

  • ツール診断：診断ツールが自動で多数の検査用リクエストを送り、反応から脆弱性を判定します。短時間で広く調べられ、費用も抑えやすい反面、誤検知（脆弱性ではないのに指摘される）や見落としが起こりえます。
  • 手動診断：診断員が画面遷移や業務ロジックを理解したうえで、手作業で検査します。ログイン後の機能や、権限の取り違え、購入フローの不備のように、ツールが苦手な箇所を調べられます。費用と期間はかかります。

実務では、ツールで広く調べ、重要な画面だけ手動で深掘りする組み合わせがよく使われます。

調べる場所：外部診断と内部診断

  • 外部診断：インターネット側から、攻撃者と同じ立場で公開部分を調べます。公開しているWebサイトの点検の中心です。
  • 内部診断：社内ネットワークなど内側から、サーバーや機器を調べます。外部からは見えない設定の不備や、侵入された後の被害の広がりやすさを確認できます。

診断の対象：Webアプリケーションとプラットフォーム

診断の対象も大きく2つに分かれます。Webアプリケーション診断は、サイト独自の画面や入力欄、ログイン機能などを調べます。プラットフォーム診断は、OSやミドルウェア、開いているポートなど、アプリの下の土台を調べます。サイトスカウターのサーバー情報調査は、このどちらの診断にも当たりません。

図3　診断で調べる範囲
アプリケーション入力欄・ログイン・業務ロジックミドルウェアWebサーバー・DB・CMSOS・サーバー更新状況・不要なサービスネットワーク開放ポート・通信経路

サイト セキュリティ 診断を自分でする：最低限の点検5項目

外部の診断を依頼する前に、運営者がすぐ確認できる項目があります。いずれも、他人ではなく自分が管理するサイトで行う点検です。

1. ソフトウェアの更新

CMS（WordPressなど）、テーマ、プラグイン、ライブラリ、PHPなどの実行環境が最新の修正版かを確認します。公開済みの脆弱性が未修正のまま放置されているサイトは、攻撃者にとって見つけやすい標的です。使っていないプラグインやテーマは、無効化ではなく削除します。自動更新が使えるなら有効にし、更新前にバックアップを取る運用にしてください。

2. 管理画面の保護

管理画面のURLが推測されやすいままでも、まず守るべきはログイン手段です。推測されにくいパスワード、2段階認証、ログイン試行回数の制限に加え、可能ならIPアドレスで接続元を絞ります。設定例は後述のApache・Nginxの例のとおりです。203.0.113.10は文書用のダミーIPなので、自分の固定IPに置き換えてください。

3. HTTPSと証明書

全ページをHTTPSで配信し、HTTPのアクセスはHTTPSへ転送します。証明書の期限切れや、ホスト名の不一致がないかも確認します。ブラウザに警告が出る場合はプライバシーエラーの解説記事、HTTPSを強制する仕組みはHSTSの解説記事を参照してください。

4. セキュリティヘッダー

Strict-Transport-Security、Content-Security-Policy、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policyなどを送っているか確認します。コマンドラインなら次で見られます。

curl -sI https://example.com/

各ヘッダーの役割と設定例はこちらの記事にまとめています。

5. ディレクトリの露出

ディレクトリ一覧が表示される設定や、バックアップファイル（.bakや.zip）、設定ファイル、.gitフォルダなどが公開領域に置かれたままになっていないかを確認します。公開領域にあってはいけないファイルを置かないことが前提で、そのうえで一覧表示を止めておきます。

Apache・Nginxの設定例

項目2・3・5と、バージョン情報の露出を抑える設定をまとめた例です。ApacheのOptions -Indexesを.htaccessで使うには、サーバー側で上書きが許可されている必要があります。

Apache

# ディレクトリ一覧表示を無効化（.htaccess または仮想ホスト）
Options -Indexes

# 管理画面を特定のIPだけに制限（Apache 2.4）
<Directory "/var/www/html/admin">
  Require ip 203.0.113.10
</Directory>

# バージョン情報の露出を抑える（サーバー全体の設定）
ServerTokens Prod
ServerSignature Off

Nginx

# ディレクトリ一覧表示を無効化
autoindex off;

# 管理画面を特定のIPだけに制限
location /admin/ {
    allow 203.0.113.10;
    deny  all;
}

# バージョン情報の露出を抑える（http ブロック）
server_tokens off;

# HTTP から HTTPS へ転送（80番の server ブロック）
return 301 https://$host$request_uri;

設定変更後は、必ず設定テスト（Apacheはapachectl configtest、Nginxはnginx -t）を行ってから再読み込みし、自分のブラウザやcurlで挙動を確かめてください。

図4　自分でできる最低限の点検
ソフトウェア更新CMS・プラグイン・実行環境が最新管理画面2段階認証・IP制限・試行回数制限HTTPS全ページHTTPS・証明書が有効セキュリティヘッダー主要6種が送信されているディレクトリ露出一覧表示なし・バックアップ無しバージョン露出ヘッダーにバージョン番号なし

サイトスカウター /server/ で見られる範囲と見られない範囲

サイトスカウターのサーバー情報調査は、前章の点検のうち、外から見える設定の一部を自動で確認するツールです。脆弱性診断サービスの代わりにはなりません。実装に基づいて、できることとできないことを分けて示します。

調べていること（非侵襲の範囲）

調査は、第三者のサーバーに負担や危険を与えない範囲に限定しています。行うのは次のことだけです。

  • DNSの照会（A・AAAA・MX・NS・TXT・SOA・CNAME、逆引き、ASNの照会）
  • ドメインのWHOIS、IPアドレスの保有者情報（RDAP）
  • TLSハンドシェイク1回によるサーバー証明書の取得
  • HTTPのGETリクエスト1回によるレスポンスヘッダーの確認
  • DNSブラックリスト（DNSBL）6リストへの掲載確認
  • IPアドレスからの、おおよその所在地の取得

これらから、次のセキュリティ項目を判定します。

  • HTTPSに対応しているか
  • 証明書の有効性（期限切れ・自己署名・ホスト名の不一致はNG、残り30日未満は警告）
  • 6種類のセキュリティヘッダー（HSTS、CSP、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy）の有無
  • CookieのSecure・HttpOnly・SameSite属性（Cookieが返された場合）
  • ServerやX-Powered-Byヘッダーに、バージョン番号らしき表記が出ていないか
  • DNSブラックリストへの掲載

調べていないこと（見られない範囲）

ポートスキャンや脆弱性の探索は実装していません。したがって、次のことは分かりません。

  • SQLインジェクション、XSS、CSRFなど、入力値を扱うコードの脆弱性
  • ログイン後の画面や、権限の不備（アクセス制御の問題）
  • CMSやプラグインが最新かどうか（バージョンがヘッダーに出ている場合に「露出」として指摘するだけです）
  • 管理画面の保護状況、ディレクトリ一覧の表示、公開領域に置かれたバックアップファイル
  • 開いているポートや、動いている不要なサービス
  • ヘッダーの中身が適切か（存在するかしか見ていません。たとえばCSPが十分に厳しいかは評価しません）

ここで「問題なし」と表示されても、サイトが安全であるという意味ではありません。見ているのは、HTTP応答1回分から分かる設定面だけです。逆に、警告が出た項目は、前章の設定例で比較的すぐ直せるものが中心です。入口の確認として使い、本格的な診断が必要かどうかの判断材料にしてください。

図5　/server/ の守備範囲
×　見られる×HTTPS・証明書の状態×6種のヘッダーの有無×Cookie属性×バージョン露出×DNSBLへの掲載○　見られない○SQLi・XSSなどのコード不備○ログイン後の機能○管理画面・露出ファイル○開放ポート・不要サービス○ヘッダー値の妥当性

外部の脆弱性診断サービスを選ぶときの観点

公開サイトで会員情報や決済を扱う場合や、重要なシステムでは、専門事業者の診断を検討します。選ぶときの観点を整理します。

公的な基準・資料を物差しにする

  • 情報セキュリティサービス基準適合サービスリスト：経済産業省が策定した「情報セキュリティサービス基準」への適合が審査されたサービスを、IPAが公開しているリストです。「脆弱性診断サービス」の区分があります。IPAは、リストに載っていることがサービスや事業者への保証ではないとも明記しています。一次情報として使いつつ、最終的には自分で内容を確認してください。
  • 脆弱性診断士（Webアプリケーション）スキルマップ：ISOG-JとOWASP Japanが公開した、診断に必要な技術・知識の整理です。担当者の力量を考える際の目安になります。
  • IPA「安全なウェブサイトの作り方」：診断項目の比較対象になります。見積もりの検査項目に、同資料の7つの脆弱性が含まれているかを確認できます。
  • 政府情報システムにおける脆弱性診断導入ガイドライン（デジタル庁）：政府機関向けですが、診断を導入する際の考え方を知る資料として参考になります。

見積もりと契約で確認すること

  1. 対象範囲：URLやドメイン、画面数、API、ログイン後の機能まで含むか。
  2. 手法：ツール診断のみか、手動診断を含むか。
  3. 診断環境：本番環境か検証環境か。本番で行う場合の時間帯、負荷、障害時の連絡手順。
  4. 成果物：危険度の評価、再現手順、具体的な修正方法が書かれた報告書か。
  5. 再診断：修正後の確認が含まれるか。
  6. 事前の許可：ホスティング会社やクラウド事業者が診断を許可しているか、申請が必要か。
  7. 診断で知り得た情報の扱い：秘密保持と、データの廃棄についての取り決め。

診断は一度受けて終わりではありません。サイトを改修するたび、また新しい脆弱性が公表されるたびに状況は変わります。リリース前と定期的な見直しを、運用に組み込んでください。

図6　診断サービスを選ぶ流れ
1目的と対象を決める2基準適合リストで探す3見積もりの範囲を比較4事前許可を確認5診断→修正→再診断

他人のサイトに無断で診断ツールを使ってはいけない理由

診断ツールは、自分が管理するサイト、または管理者から書面などで明確な許可を得たサイトにだけ使ってください。興味本位や「善意で調べてあげる」つもりでも、他人のサイトに対して無断で脆弱性を探る行為は、トラブルの原因になります。

不正アクセス禁止法の基本

「不正アクセス行為の禁止等に関する法律」は、第3条で「何人も、不正アクセス行為をしてはならない」と定めています。第2条では、不正アクセス行為の例として、他人のID・パスワード（識別符号）を入力してアクセス制限を解除する行為、アクセス制御機能による制限を免れることができる情報や指令を入力して、制限された利用をできる状態にする行為などが挙げられています（管理者の承諾を得てするものは除かれます）。第11条では、第3条に違反した場合の罰則として、3年以下の拘禁刑または100万円以下の罰金が定められています。

これは法律の一部を紹介したものであり、どの行為が該当するかは個別の事情によるため、法的な助言ではありません。判断に迷う場合は、弁護士などの専門家や、警察の相談窓口（警察相談専用電話 #9110）に相談してください。

許可があっても気をつけること

  • 診断ツールは大量のリクエストを送るため、サーバーに負荷をかけ、サービスに支障が出ることがあります。
  • ホスティングやクラウドの規約で、診断に事前申請が必要な場合があります。
  • 許可は対象と期間を明確にし、記録を残してください。

脆弱性を見つけてしまったら

偶然、他人のサイトの問題に気づくこともあります。その場合に、自分でさらに試して確かめる必要はありません。まずはIPAなど公的機関の、脆弱性に関する届出窓口の案内を確認してください。

サイトスカウターのサーバー情報調査は、DNS・WHOIS・証明書・HTTPヘッダー1回分といった、公開情報と通常のアクセスで得られる範囲に限っています。この方針は、他人のサイトも調べられるツールであるからこそ守っている線引きです。

診断の次の一歩：優先順位のつけ方

点検で問題が見つかったら、次の順番で対処すると効率的です。

  1. 公開されている重大な問題の解消：更新されていないCMSやプラグイン、期限切れの証明書、管理画面の無防備な公開。
  2. 設定だけで直せるものの対応：セキュリティヘッダー、ディレクトリ一覧の停止、バージョン情報の非表示。
  3. コードの修正が必要なものの確認：プレースホルダの利用、出力時のエスケープ。自作のフォームや検索機能がある場合は特に重要です。
  4. 専門事業者による診断の検討：会員情報や決済情報を扱う場合、改修が大きい場合。

自分のサイトの設定面は、サーバー情報調査で現状を把握できます。ドメインの履歴や被リンクなど、サイト全体の状態を見たいときはドメイン査定も使えます。

サイトスカウターで調べる

自分のサイトのHTTPS・証明書・セキュリティヘッダーの設定状況は、サーバー情報調査にURLを入れるだけで確認できます（コードの脆弱性までは調べません）。

サーバー情報調査を使う

よくある質問

脆弱性診断とペネトレーションテストの違いは何ですか？

脆弱性診断は、システムの弱点を網羅的に洗い出す検査です。ペネトレーションテストは、攻撃者の視点で弱点を実際に使い、侵入や情報取得などの目的を達成できるかを確かめる検査です。ただし、言葉の線引きは事業者によって異なるため、依頼するときは対象範囲・手法・成果物を確認してください。

Webサイトの脆弱性診断は自分でできますか？

ソフトウェアの更新、管理画面の保護、HTTPS、セキュリティヘッダー、ディレクトリの露出といった基本的な点検は、運営者が自分のサイトで行えます。ただし、SQLインジェクションやXSSなどコードの脆弱性やログイン後の機能は、専門の診断やコードレビューが必要です。

OWASP Top 10とは何ですか？

Webアプリケーションで重大なリスクになりやすい10分類をまとめた、OWASPの資料です。公式サイトの2025年版には、アクセス制御の不備、セキュリティの設定ミス、ソフトウェアサプライチェーンの不備、インジェクションなどが掲載されています。版ごとに分類は変わるため、参照するときは何年版かを確認してください。

サイトスカウターのサーバー情報調査で脆弱性は見つかりますか？

いいえ。ポートスキャンや脆弱性の探索は行っていません。HTTPS・証明書、6種類のセキュリティヘッダーの有無、Cookie属性、バージョン情報の露出、DNSブラックリストへの掲載など、外から見える設定面の一部を確認するツールです。SQLインジェクションやXSSの有無は判定できません。

他人のサイトに脆弱性診断ツールを使ってもよいですか？

管理者の許可なく使うべきではありません。不正アクセス禁止法は、アクセス制御を回避して制限された利用をできる状態にする行為などを禁止し、違反した場合の罰則も定めています。個別の判断は専門家や警察の相談窓口（#9110）に確認してください。

外部の脆弱性診断サービスはどう選べばよいですか？

経済産業省の基準に適合したサービスを掲載するIPAのリストなど、公的な情報を手がかりにしつつ、対象範囲、ツールか手動か、診断環境、報告書の内容、再診断の有無、事前許可の要否を比較してください。

出典・参考資料

最終確認日：2026-10-06。制度・仕様は変更されることがあるため、実施前に各一次情報をご確認ください。

本記事は一般的な情報提供を目的としており、法的助言ではありません。被害に遭われた場合や判断に迷う場合は、消費者ホットライン（188）や警察相談専用電話（#9110）などの公的窓口にご相談ください。