簡易チェックと脆弱性診断の違いは、調べる深さと許可の要否

簡易チェックは、ブラウザが普通に受け取る応答を読むだけで、攻撃にあたる通信を送りません。脆弱性診断とペネトレーションテストは疑似的な攻撃を送るため、システムの管理者の承諾と、範囲や日時の合意が前提になります。

経済産業省の『情報セキュリティサービス基準』(第4.1版)は、脆弱性診断サービスを3つに分けています。Webアプリケーション、プラットフォーム、スマートフォンとタブレットのアプリケーションの診断です。ペネトレーションテストは、そのうち攻撃者と同じ手法でセキュリティ機能を回避し、攻撃の目的を達成できるかを試験するサービスとされています。

無料ツールでできることと、できないこと

無料ツールは、外形を受動的に確かめるものと、疑似攻撃を送るOSSのスキャナーに分かれ、できる範囲と注意点が大きく違います。どちらを使っても、他人のデータが見える、手順を飛ばせるといった権限や業務の流れの欠陥は見つけられません。

外から見るだけの簡易チェック

自社の無料のWebサイトのセキュリティチェック(Security Checker X)は、この受動的な型です。公開ページの取得(GET、HEAD、OPTIONS)、DNSの照会、TLSの接続確認だけで、7カテゴリ、90を超える項目を30秒から90秒ほどで確かめます。項目の全体像はWebサイトのセキュリティチェック項目30選にまとめています。

• HTTPSとSSL/TLS証明書の期限、TLS 1.0やTLS 1.1などの古い通信方式の受け入れ
• HSTSやCSPなどのセキュリティヘッダーと、CookieのSecure、HttpOnly、SameSite属性
• .gitや.env、SQLダンプ、ディレクトリリスティングなど、公開されてはいけないもの
• Webサーバー、PHP、WordPress、JavaScriptライブラリの版と、既知の脆弱性(CVE)、サポートの終了
• SPFとDMARCの設定(詳しくはDMARC、SPF、DKIMのチェッカーで確かめられます)

攻撃コードの送信、ログインの試行、入力欄への値の送信、80番と443番以外のポートの確認は行いません。そのため、ログインが必要な領域と、アプリケーション固有の脆弱性は対象外です。WAFなどに遮られて確かめられなかった項目は『検査できなかった項目』として表示し、問題がないとは扱いません。

疑似攻撃を送るOSSの診断ツール

ZAPやOpenVASのような無料のOSSは、疑似攻撃を送る能動的なツールです。経済産業省は、基準とあわせて『情報セキュリティサービスにおける技術及び品質確保に資する取組の例示』(以下、取組の例示)を公表しています。この例示にも、Webアプリケーション診断とプラットフォーム診断で使うツールの例として、OWASP ZAPとOpenVASが載っています。

ZAPの公式文書は、能動スキャンを対象への攻撃と位置づけ、自分が所有しないWebアプリケーションに使ってはいけないと明記しています。同じ文書は、アクセス制御の不備のような論理的な脆弱性は自動のスキャンでは見つからないとし、手動のペネトレーションテストの併用を求めています。

デジタル庁の『政府情報システムにおける脆弱性診断導入ガイドライン』(DS-221)は、診断の種類の選び方から報告書の要件までを定めた参考文書です。この文書は、プラットフォーム診断をフリーツールや自社製のツールだけで行わないことを要件にしています。無料のOSSは自社の検証環境で傾向をつかむ道具と考え、取引先に示す診断とは分けて扱います。

無料ツールでは見つからない欠陥

DS-221は、Webアプリケーションの脆弱性を、仕様に起因するもの、実装に起因するもの、ミドルウェア固有のものに分けています。ツールが特に苦手とするのは、次のような欠陥です。

• 他人のデータを読み書きできる、管理者の機能を一般の会員が使える(認可の不備)
• パスワードの再設定の悪用や、ID連携の不備による、なりすまし
• 1回の注文に1回だけのはずの割引を、何度も使える
• 同時に操作するとデータが食い違う、レースコンディション

OWASPの『Web Security Testing Guide』も、業務ロジックの欠陥は脆弱性スキャナーでは検出できず、検査する人の技能と創造性に頼ると述べています。

ツール診断と手動診断の違い

ツール診断は、型の決まった不備を短い時間で広く拾い、手動診断は、画面の意味や権限の関係を理解して、ツールが見落とす欠陥を探します。DS-221は、ツールによる自動の診断だけでは不十分で、専門家による手動の診断との併用が不可欠としています。

仕様に起因する欠陥と、実装の高度な理解が要る欠陥は、ツールの誤検出を除くだけでなく、診断そのものを人手で行うのがDS-221の要件です。ツールを使う場合も、診断対象の見落としや誤検出が含まれないよう、手動で精査することを求めています。

プラットフォーム診断とWebアプリケーション診断の違い

プラットフォーム診断はサーバーやネットワーク機器のOS、ミドルウェア、開いているポートを調べ、Webアプリケーション診断は画面やAPIの処理を調べます。調べる層が違うため、片方だけを受けても、もう片方の層の弱点は残ります。

表の内容の出典は、DS-221の種別の説明です。レンタルサーバーやSaaSでサイトを動かしている場合、OSやミドルウェアの管理は提供元にあります。DS-221はインフラの提供者が禁止している診断項目を避けるよう求めているので、プラットフォーム診断を頼む前に、提供元の規約と申請の手続きを確かめます。

スマートフォンアプリを提供しているなら、アプリ本体と、アプリとサーバーの間の通信を調べるスマートフォンアプリ診断も対象になります。

自社でできることと、専門家に頼む場面の判断基準

判断の分かれ目は、ログインした後の機能と、守るべき情報があるかどうかです。上の行から順に確かめ、『はい』になった行の対応をとります。全て『いいえ』なら、下の『自社で今日できること』と定期の簡易チェックを続けます。

自社で今日できること

• 自社サイトを無料の簡易チェックにかけ、『緊急』と『高』の指摘から直して、もう一度確かめる
• ドメイン、サブドメイン、サーバー、CMS、プラグイン、外部サービスの一覧を作る(範囲を決める時の台帳になる)
• CMSの本体、プラグイン、テーマを更新し、使っていないものを削除する(手順はWordPressの脆弱性を確認する方法)
• .gitや.env、バックアップファイルが公開されていないか確かめる(.gitや.envの公開を確認する方法)
• HTTPSとセキュリティヘッダーを整える(HSTSやCSPの設定方法)
• 管理画面に、接続元の制限か多要素認証を入れる
• 脆弱性の連絡窓口を、security.txtで公開する
• 制作会社や保守会社との契約で、脆弱性を直す責任と費用の分担を確かめる

security.txtは、外部の人が見つけた脆弱性の連絡先を示すファイルで、RFC 9116が形式を定めています。HTTPSで /.well-known/security.txt に置き、ContactとExpiresが必須の項目です。Expiresは、1年より先の日付にしないことが推奨されています。

# 例: https://example.com/.well-known/security.txt に置く内容
Contact: mailto:security@example.com
Expires: 2027-09-30T23:59:59+09:00
Preferred-Languages: ja, en

簡易チェックと診断を順番に使う運用の流れと時期

まず簡易チェックで外から見える不備を直し、範囲を決めて専門家の診断を受け、報告書で決めた順番で直して再診断で閉じます。その後は、設定や部品を変えるたびと定期的に、簡易チェックへ戻ります。

1. 簡易チェックで外形を確かめる受動的なチェックで、証明書、ヘッダー、公開ファイル、古い版を確かめます。
2. 自社で直せるものを直す設定の追加と更新で直る指摘を片付け、もう一度チェックして消えたことを確かめます。
3. 範囲を決める台帳から対象を選び、深さと環境を決めます。決め方は次の節で説明します。
4. 専門家の診断を受けるツールと手動を組み合わせ、ログイン後の権限や業務の流れまで調べてもらいます。
5. 報告書で直す順番を決める深刻度を自社の環境で読み替え、指摘ごとに担当と期限を決めます。
6. 直して再診断で閉じる直した指摘を再診断で確かめ、受け取った報告書を版ごとに保管します。

この順番にするのは、簡易チェックで分かる設定の不備を残したまま診断すると、有償の時間と報告書がその指摘に割かれるためです。先に片付けておけば、診断の時間を、ツールの届かない権限や業務の流れの検査に充てられます。

診断を行う時期と契機

DS-221は、新規の構築や機能の追加で行う『構築時診断』と、点検や監査として行う『定期診断』を分けています。Webアプリケーションで診断が望ましい変更として挙げるのは、入力の処理、動的な画面の生成、認証やファイルのアップロードなどの追加や変更と、開発会社の交代です。

定期診断を同じ条件で繰り返すと、初回の後は脆弱性が検出されにくくなります。そのためDS-221は、範囲、事業者や担当者、ツールや手法を変えることを勧めています。周期の数字は示さず、各機関の自己点検や監査の計画に沿って行うものとしています。

クレジットカード決済を扱うECサイトには、より具体的な目安があります。『クレジットカード・セキュリティガイドライン』は、割賦販売法の義務の実務上の指針とされています。2025年4月からは、全てのEC加盟店に、チェックリストに記載した脆弱性対策などの実施を求めています。

クレジット取引セキュリティ対策協議会の導入ガイド(2.1版、2026年3月)は、その対策の1つに『脆弱性診断又はペネトレーションテストの定期実施』を挙げています。

診断の範囲の決め方

範囲は、インターネットから届く場所と、変更した場所から先に決め、同じ作りの画面は代表に絞ります。対象の量、つまりIPアドレスの数や、画面とリクエストの数が、見積もりと日数を左右します。

1. 台帳から対象を洗い出すドメイン、IPアドレス、画面、API、外部との連携を一覧にします。DS-221は、台帳の抜け漏れを防ぐ手段に、聞き取りのほか、OSINTやASM(Attack Surface Management)のサービスを挙げています。
2. 優先する場所を決める初めてなら、インターネットから届く箇所を優先します。個人情報、決済、管理機能に触れる画面と、前回の診断の後に変えた画面を先に入れます。
3. 画面を機能の種類で選ぶIPAの『ウェブ健康診断仕様』は、ログイン、パスワード変更、入力内容確認、DB更新、メール送信、認可制御のある画面などの種類を定め、その種類から診断する画面を選ぶ方式です。同じ作りの画面が複数あれば代表の1画面に絞る方針も、DS-221が例に挙げています。
4. 深さと基準を決めるどの基準で調べるかを、事業者に示してもらいます。経済産業省の『取組の例示』は、Webアプリケーション診断の基準の例に、OWASPのASVSのレベル1以上と、IPAの『ウェブ健康診断仕様』などを挙げています。
5. 環境と権限を決める本番か、本番と同じ構成の検証環境かを決め、権限ごとにテスト用のアカウントを用意します。DS-221は、WAFやIPSが脆弱性の存在を隠すおそれがあるとして、診断の間は無効にすることを推奨しています。

DS-221は、政府情報システムの定期診断を調達する時に、対象の数の上限を決めておくよう勧めています。目安は、プラットフォーム診断で10から30のIPアドレス、Webアプリケーション診断で50から100のリクエストです。民間のサイトでも、最初の見積もりで量の感覚をつかむ参考になる数字です。

見積もりを頼む時は、次のような範囲の定義を添えると、事業者ごとの前提がそろいます。

【診断の範囲の例(見積もりの依頼に添える)】
目的: 会員機能の公開前の確認。取引先へ報告書を提出する
種別: Webアプリケーション診断(ツールと手動の併用)
対象: https://www.example.com/member/ 以下の画面とAPI(一覧は別紙)
権限: 一般会員、管理者(権限ごとにテスト用アカウントを2つ用意)
対象外: 決済代行会社の画面、外部のメール配信サービス
環境: 検証環境(本番と同じ構成)。WAFは診断の間だけ無効にする
日時: 平日22時から翌6時。中止の連絡先: 運用担当(氏名、電話番号)
成果物: 報告書(PDF)、報告会、再診断1回(報告書の受領から1か月以内)

依頼先の選び方と、情報セキュリティサービス基準の審査登録

依頼先の最初のふるいは、経済産業省の『情報セキュリティサービス基準』に適合し、IPAのリストに載っているかどうかです。そのうえで、手動で調べる範囲、報告書の中身、再診断の扱いを、見積もりの段階で確かめます。

この制度では、サービスが基準の技術要件と品質管理要件を満たすかを審査登録機関が審査し、IPAが情報セキュリティサービス基準適合サービスリストとして公開します。審査登録機関は日本セキュリティ監査協会(JASA)で、リストの公開は2018年6月に始まりました。基準の最新版は第4.1版で、2025年3月31日に公表、4月1日に施行されています。

リストに載る脆弱性診断サービスは、資格や実績のある責任者がいて、品質を管理する仕組みがあることを、第三者が審査したサービスです。自社で事業者の技術力を見極められない時ほど、この審査が判断の土台になります。

技術要件では、技術責任者を置き、要件ごとの人数を示します。技術責任者の要件は、資格(例として情報処理安全確保支援士)、専門家コミュニティでの講師やリーダーの経験、過去3年間で5件以上の実績、指定の研修の修了のいずれかです。品質管理要件では、品質管理の担当者の割り当てと、提供の過程と成果物を管理するマニュアルの整備が求められます。

見積もりの段階では、次の点を確かめます。

• 依頼したい区分(Webアプリケーション診断、プラットフォーム診断など)で、基準適合サービスリストに載っているか
• 参照する基準(OWASPのASVS、IPAの『ウェブ健康診断仕様』など)と、手動で調べる範囲が書かれているか
• ツールの出力を人が精査し、悪用できるかを可能な範囲で確かめるか
• 報告書の見本に、脆弱性の概要、深刻度とその根拠、影響、対策、検出したパラメータが載っているか
• 報告会があり、検査した人が質問に答えるか
• 再診断が含まれるか。回数と、報告書の受領から何日以内かが決まっているか
• 重大な脆弱性を見つけた時の速報と、障害が起きた時の中止の手順があるか
• 検査で得た情報の管理と、診断後の削除の方法が契約に書かれているか

DS-221は政府情報システム向けの参考文書ですが、報告書の納品後、少なくとも1か月の間に1回以上の再診断を行えることを、調達の必須要件にしています。民間でも、見積もりを比べる時の物差しにできます。

範囲の整理や、見積もりの比べ方に迷う時は、当社の診断や対策のご相談窓口でもお受けしています。

診断の前に準備すること

準備の中心は、診断で起きうる影響を先に潰すことです。サイトが止まる、データが残る、メールが大量に送られる、監視のアラートが鳴るといった影響を、承諾、バックアップ、連絡で防ぎます。

DS-221は、診断に伴う主なリスクを7つ挙げています。通信の帯域の圧迫、サービスの停止、疑似攻撃の文字列を含むデータの残存、大量のメールの送信、データの破損や損失、個人情報や機密情報の意図しない閲覧、監視のアラートの発生です。

1. 承諾を書面でそろえるシステムの責任者に加え、開発会社、運用会社、サーバーやクラウドの提供者の承諾をとります。提供者が禁止している診断項目は、範囲から外します。
2. 環境と時間帯を決める検証環境で行うか、本番で行うならバックアップをとり、休日、夜間、メンテナンスの時間帯を選びます。
3. テスト用のアカウントとデータを用意する権限ごとにアカウントを作り、消してよいテスト用のデータを入れておきます。
4. 外への送信を止める問い合わせフォームの通知先をテスト用に変え、決済はテストモードにして、実在の人にメールや請求が届かないようにします。
5. 監視と窓口に知らせる監視の担当者と問い合わせ窓口に、診断の日時と診断元のIPアドレスを伝え、アラートを攻撃と取り違えないようにします。
6. 中止の手順を決める異常が起きた時に誰が止め、誰に連絡するかを決め、事業者と共有します。
7. 診断の後に片付ける残ったテスト用のデータとアカウントを削除し、無効にしたWAFなどの設定を元に戻します。

報告書の読み方と、直す順番

報告書は、深刻度の数字を並べるだけでなく、自社の環境で読み替えて直す順番を決めます。DS-221も、CVSSの基本値は脆弱性の技術的な特性を示すもので、それだけで対応の優先度を決めるべきではないとしています。

深刻度には、CVSSの基本値(0.0から10.0)がよく使われます。IPAの解説では、9.0以上が緊急、7.0から8.9が重要、4.0から6.9が警告、0.1から3.9が注意です。事業者が独自の基準で評価している場合も、DS-221はCVSSの基本評価基準と同等に扱うよう勧めています。

DS-221は、悪用する攻撃がすでに観測されている脆弱性には、対応の基準にかかわらず迅速に対応するとしています。IPAの『ウェブ健康診断仕様』は、利用者の関与がなくても攻撃者が直接攻撃でき、大量の情報漏えいや改ざんにつながるものを危険度『高』としています。

直し方は、原因をなくす根本的な対策と、影響を減らす保険的な対策に分けて決めます。IPAの『安全なウェブサイトの作り方』も、この2つを分けて示しています。根本的な対策に時間がかかる時は、WAFの設定などで当面をしのぎ、期限を決めて本来の修正を行います。

診断の費用は何で決まるか

診断の費用は、対象の量、調べる深さ、診断の条件、報告と再診断の範囲の4つで決まります。金額を比べる前に、範囲と深さをそろえた見積もりかどうかを確かめてください。

• 対象の量: プラットフォーム診断はIPアドレスの数、Webアプリケーション診断は画面やAPIなどのリクエストの数で変わります(DS-221)。
• 調べる深さ: 手動で調べる割合、権限の種類の数、仕様に起因する欠陥まで調べるかで変わります。
• 診断の条件: 夜間や休日の作業、通信の帯域の制限、現地での内部診断などです。DS-221は、現地での診断に追加の費用が生じることがあるとしています。
• 報告と再診断: 報告会の有無、再診断の回数と期限、経営層向けの要約の有無で変わります。

費用を抑える近道は、範囲を削ることより、診断の前に直せるものを直しておくことです。構築時の診断は追加や変更した部分に絞る、同じ作りの画面は代表に絞る、といった量の調整も事業者と相談できます。見積もりを比べる時は、ツールの出力を人が分析する作業が含まれているかも確かめます。

許可のない診断は不正アクセス禁止法に触れるおそれがある

他者のサイトに、管理者の承諾なく脆弱性を突く通信を送ると、不正アクセス禁止法の『不正アクセス行為』にあたるおそれがあります。自社のサイトでも、サーバーを他社が管理している場合は、その管理者の許可を事前に得ます。

法律は、他人のIDやパスワードを入力する行為(第2条第4項第1号)を不正アクセス行為としています。アクセス制御の制限を免れる情報や指令を入力し、本来は使えない機能を使える状態にする行為(同第2号、第3号)も同じで、いわゆるセキュリティホールを突く行為です。

アクセス管理者本人と、その承諾を得た人の行為は除かれ、警察庁の解説は、その理由をセキュリティチェックのような正当な利用があるためと説明しています。違反した場合の罰則は、3年以下の拘禁刑または100万円以下の罰金です(第11条)。2025年6月1日に刑法などの改正にあわせて『懲役』が『拘禁刑』に改められたため、官公庁の解説には改正前の表記が残っているものがあります。

よくある質問

関連記事Webサイトのセキュリティチェック項目30選 関連記事SSL/TLS証明書のチェック方法 関連記事セキュリティヘッダーの設定方法 関連記事.gitや.envが公開されていないか確認する方法と、見つかった時の対処 関連記事WordPressの脆弱性を確認する方法

The post 簡易チェックと脆弱性診断の違い|無料ツールでできることと、専門業者が必要な場面 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

セキュリティチェックの30項目は、外から17、管理画面と契約で13を確かめる

セキュリティチェックの30項目は、確かめる場所で2つに分かれます。公開ファイル、通信、HTTPヘッダー、DNSの17項目は外から、更新、ログイン、運用の13項目は管理画面と契約書で確かめます。

外から確かめられる設定は、攻撃者にも同じように見えています。証明書の期限切れや公開されたファイルは、URLを知っていれば誰でも気づけます。

管理画面の項目は外から見えないため、無料ツールでは確かめられません。IPAの『安全なウェブサイトの運用管理に向けての20ヶ条』も、パスワード、アカウント、ログといった運用の条項を多く含みます。

今日15分でできる最初の点検

最初の15分は、見つかったときの被害が大きい5点に絞ります。ブラウザとCMSの管理画面があれば、専門の道具は要りません。

1. 公開ファイルを開いてみる(2分)ブラウザで自社ドメインの /.git/HEAD と /.env を開きます。『見つかりません』や『Forbidden』と出れば合格です。設定値のような文字が表示されたら、ほかの作業より先に項目1の対処へ進みます。
2. 証明書の期限を見る(2分)アドレスバーの鍵アイコンから証明書を開き、有効期限を確かめます。残りが30日を切っていたら、自動更新が動いているかをサーバーの管理画面で見ます。
3. 更新とログインの守りを見る(5分)CMSの管理画面で、本体とプラグインに未適用の更新がないかを見ます。管理者アカウントで2段階認証が有効か、パスワードをほかのサービスと使い回していないかも確かめます。
4. バックアップの最終日を見る(3分)サーバーの管理画面で、最後に取得した日と保存先を確かめます。更新を当てるのは、この確認の後です。
5. 外から見える設定をまとめて診断する(3分)無料のWebサイトセキュリティチェックにURLを入れ、重大度が『緊急』と『高』の指摘だけを書き出します。登録は要らず、通常30秒から90秒で結果が出ます。

ターミナルを使える場合は、次の2行で項目5、6、9、11〜13の応答をまとめて確かめられます。1行目のようにスキームを省くと、curlはhttpで接続します。

curl -I example.com
curl -I https://example.com/

例: 1行目の応答(この形なら項目6は合格)
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

例: 2行目の応答で探すヘッダー
strict-transport-security: max-age=31536000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff

外から確かめる17項目(公開ファイル、通信、ヘッダー、DNS)

外から確かめる17項目は、ログインせずに、ブラウザ、curl、無料ツールで確かめられます。表は、確認方法と合格の目安、放置の危険、直し方の順に並べています。

公開してはいけないファイルとページ(項目1〜5)

よく使われるファイル名は、URLを推測して機械的に試せます。OWASPの検査ガイド(WSTG-CONF-04)も、.bak などの古い写しがソースコードや認証情報を表示する危険を挙げています。確認は、自社のサイトだけに限ります。

# Apache(.htaccess)の例: .git、.svn、.env を含むURLに404を返す
RedirectMatch 404 /\.(git|svn|env)

# nginxの例: 同じURLへのアクセスを拒否する(403を返す)
location ~ /\.(git|svn|env) {
    deny all;
}

どちらの例も、証明書の自動更新が使う /.well-known/ には影響しません。見つかった後の手順は、.gitや.envが公開されていたときの確認と対処で扱っています。

通信の暗号化と証明書(項目6〜10)

HTTPSは、入力内容を盗み見と書き換えから守る土台です。20ヶ条でも、通信の暗号化は独立した1条になっています。SSL/TLS証明書の詳しい見方は、SSL/TLS証明書のチェック方法で扱っています。

HTTPヘッダーとCookie(項目11〜14)

セキュリティヘッダーは、ブラウザに備わった防御を有効にする設定です。確認はどれも、curl -I の応答を1回見れば済みます。書き方の例は、セキュリティヘッダーの設定方法にまとめています。

APIを公開しているサイトは、Access-Control-Allow-Origin が * や、受け取ったオリジンをそのまま返す設定になっていないかも確かめます。

DNSとメール認証(項目15〜17)

自社ドメインを名乗るなりすましメールは、サイトに触れずに顧客や取引先を狙います。IPAの情報セキュリティ10大脅威2026でも、ビジネスメール詐欺が組織向けの10位に入りました。メール認証は、受け取る側に本物かどうかを判断させる仕組みです。

# Mac、Linux
dig TXT example.com +short
dig TXT _dmarc.example.com +short

# Windows(コマンドプロンプト、PowerShell)
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

例: 合格の形(SPFは1行だけ、DMARCはレポートの宛先あり)
"v=spf1 include:_spf.example.net ~all"
"v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"

Gmailの送信者のガイドラインは、すべての送信者にSPFかDKIMを求め、1日5,000件以上を送る送信者にはSPF、DKIM、DMARCのすべてを求めています。コマンドを使わない場合は、ドメイン名を入れるだけのDMARC、SPF、DKIMの無料診断ツールでも設定の状況を確かめられます。

管理画面と契約で確かめる13項目(更新、ログイン、運用)

管理画面と契約で確かめる13項目は、外からは見えませんが、乗っ取りを防げるか、被害から戻れるかを決めます。CMS、サーバー、ドメインの管理画面と、制作会社やサーバー事業者との契約書を手元に置いて確かめます。

ソフトウェアの更新(項目18〜21)

公表された脆弱性には、CVEという共通の番号が付きます。攻撃者はその情報を使い、対策していないシステムを狙います。10大脅威2026でも、『システムの脆弱性を悪用した攻撃』が組織向けの4位でした。

WordPressでの具体的な手順は、WordPressの脆弱性を確認する方法で扱っています。

ログインとアカウント(項目22〜25)

管理画面のパスワードは、ほかで漏れたパスワードの一覧を使って機械的に試されます。20ヶ条も、不正ログインの対策、不要なアカウント、推測されやすいパスワードを、それぞれ独立した条項にしています。CMSだけでなく、サーバー、ドメイン、DNS、メール配信の管理画面も同じ扱いです。

バックアップ、監視、体制(項目26〜30)

被害をゼロにはできないため、気づく仕組みと戻す手段を先に用意します。IPAが2026年10月9日に出した不正アクセスによる漏えい等の事案を踏まえた注意喚起も、ログの保持期間、保有データ、外部サービスの見直しを求めています。

直す順番は、被害の大きさ、見つかりやすさ、手間の3つで決める

30項目は、被害の大きさ、見つかりやすさ、直す手間と副作用の3つの物差しで、3段階に分けて直します。被害が大きく機械的に見つかるものから先に直し、表示を壊すおそれのあるものは試しながら進めます。

点検の計画: 今日15分、毎月30分、変更時と年1回の見直し

点検は一度で終わらせず、頻度を決めて回します。目安は、初回15分、毎月30分、変更したときと公開前に10分から20分、四半期に1時間、年1回に半日です。

公開前と変更したときは、次の8点を確かめてから切り替えます。作業の途中で作ったファイルやアカウントは、消し忘れやすいためです。

• 作業で作った .zip、.sql、.bak を消した(項目2)
• テスト用のアカウントと、制作会社の一時的なアカウントを消した(項目25)
• 本番のデバッグ表示を切った。WordPressは WP_DEBUG、PHPは display_errors(項目5)
• テスト環境は、Basic認証などで社外から見えない(項目4)
• 全ページがhttpsで開き、Consoleに混在コンテンツの警告がない(項目6、10)
• curl -I で、ヘッダーが意図どおりに返る(項目11〜13)
• フォームを送信し、WAFに止められず、確認メールが届いた(項目28)
• 新しく作ったサブドメインに、使い終えたら消す担当を決めた(項目17)

問題が見つかったときの初動: 記録、停止、鍵の作り直し、報告

公開ファイルや改ざんが見つかったら、記録、停止、作り直し、調査、報告の判断、再発防止の順で動きます。先にファイルを消すと、調査と報告に要る証拠まで失うためです。

1. 記録を残す見つけた日時、URL、画面のスクリーンショットを残し、サーバーのログを保全します。
2. 公開を止める問題のファイルを公開フォルダから外すか、サーバー設定で拒否します。改ざんであれば、メンテナンス表示に切り替えます。
3. 鍵とパスワードを作り直す読まれたおそれのある .env のパスワード、APIキー、管理者のパスワードを変えます。ファイルを消しても、写しを取られた鍵は使えるままです。
4. ログで範囲を調べるアクセスログで、そのURLに外部から届いたリクエストの有無と日時を確かめます。
5. 報告と通知の要否を判断する個人データが漏れたおそれがあれば、個人情報保護委員会への報告と本人への通知が必要かを判断します。
6. 再発を防ぐ原因になった手順、権限、更新の漏れを直し、点検の計画に組み込みます。

自社だけで判断が難しい場合は、制作や保守を担う会社に早めに連絡します。診断結果の読み方や直す順番の相談は、エスライン・テクノロジーズのお問い合わせ窓口でも受け付けています。

IPAの20ヶ条と、この点検表の対応

この30項目は、IPAの20ヶ条の観点を、小規模なサイトで確かめられる形に置き換えたものです。20ヶ条は2005年に掲載が始まり、2015年の全面改訂を経て、2019年3月6日に最終更新されています。

20ヶ条の3条目にある『安全なウェブサイトの作り方』の脆弱性対策は、入力フォームなどの作りを調べる必要があり、この点検表には含めていません。ただし、項目11〜14のヘッダーとCookieは、その被害を和らげる設定にあたります。

反対に、メール認証(項目15、16)、参照先のないCNAME(項目17)、証明書の自動更新(項目7)は、20ヶ条にない観点として加えました。メールの送信者への要件や、証明書の有効期間の短縮といった、最終更新後の変化に対応するためです。

無料ツール、手作業、専門家の診断の使い分け

外から見える項目は無料ツールでまとめて確かめ、管理画面の項目は自分の目で確かめます。入力フォームや会員機能の作りは、専門家の脆弱性診断が担う領域です。

手順5で使った無料ツール『Security Checker X』は、公開ページの取得、DNSの照会、TLSの接続確認だけで診断し、ログインの試行や攻撃用データの送信はしません。各指摘には『確認済み』『推定』『可能性』の確度が付くため、事実と推測を分けて読めます。診断できるのは、自社か管理権限のあるサイトだけです。

専門家に依頼するかどうかの判断は、簡易チェックと脆弱性診断の違いで整理しています。

よくある質問

項目ごとに詳しく確かめる関連記事

関連記事.gitや.envが公開されていないか確認する方法と、見つかった時の対処 関連記事SSL/TLS証明書のチェック方法 関連記事セキュリティヘッダーの設定方法 関連記事WordPressの脆弱性を確認する方法 関連記事簡易チェックと脆弱性診断の違い

The post Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.