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

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

経済産業省の『情報セキュリティサービス基準』(第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 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

WordPressの脆弱性は、版の把握と公開情報との照合で確認する

脆弱性の確認は、自分のサイトで動いている版を正確に知る作業と、その版が公開の脆弱性情報で『影響を受ける版』に入るかを照らす作業の2段階です。版が分からなければ照合できず、照合しなければ更新の優先順位も決められません。

版の把握には管理画面とWP-CLIを、照合にはWordPress公式の発表、JVN iPedia、NVDを使います。外からの確認は、攻撃者と同じ立場で、自分のサイトから何が見えているかを点検する作業です。4つの方法は、分かることと分からないことがそれぞれ違います。

脆弱性とは何か: 本体、テーマ、プラグインで起きる場所の違い

脆弱性は、ソフトウェアやWebサイトの機能や性能を損なう、セキュリティ上の問題箇所です。IPAのセミナー資料『ウェブサイトの安全な運用について』は、放置するとサイトの乗っ取りや情報漏えいなどにつながるおそれがあると説明しています。Webサーバーの設定の不備も、脆弱性とみなされます。

WordPressでは、本体、テーマ、プラグインのどこでも脆弱性は見つかります。本体はWordPressのセキュリティチームが修正版を出し、多くは自動更新で届く仕組みです。プラグインとテーマは開発者ごとに対応が分かれ、管理者が更新しない限り古い版が残ります。

本体: 2026年も重大な修正が続いている

本体でも、深刻な脆弱性は見つかります。2026年7月17日のWordPress 7.0.2は、深刻度『critical』と『high』の2件を修正しました。影響を受ける版のサイトには、自動更新の仕組みで強制的に更新が配信されています。

2件のCVE番号は、CVE-2026-60137とCVE-2026-63030です。IPAは、組み合わせると遠隔でのコード実行が生じる可能性があるとして、7月22日にWordPressの脆弱性対策についての注意喚起を出しました。

9月以降も、17日の7.1.1で11件、22日の7.1.2で深刻度『critical』の1件、10月6日の7.1.3で7件のセキュリティ修正が出ています。7.1.3の7件には、XSS(クロスサイトスクリプティング)2件やSQLインジェクションの修正が含まれます。

2026年10月12日時点の最新版は7.1.3です。公式のリリース一覧は『7.1系の最新版だけが安全に使え、積極的に保守されている』と明記しています。古い系統にも修正が移植されることはありますが、公式はこれを厚意(courtesy)と位置づけ、2025年7月には4.1から4.6へのセキュリティ更新を終えました。

プラグインとテーマ: 提供元ごとに対応が分かれる

プラグインとテーマの修正版を出すのは、それぞれの開発者です。自動更新は既定で無効で、WordPress.orgのセキュリティチームが重大な脆弱性への対応として判断した特別な場合にだけ、自動で配信されます。開発が止まったものは修正版が出ないまま残り、セキュリティ上の問題などで公式ディレクトリから閉鎖されることもあります。

サーバーのPHPも、確認の対象です。WordPress公式の動作環境のページはPHP 8.3以上を推奨し、サポートが終わった古い版はサイトを脆弱性にさらすおそれがあると注意しています。

管理画面で確認する: サイトヘルス、更新画面、プラグインの詳細

管理画面では、『ツール』→『サイトヘルス』で自動更新の不調と更新待ちを、『ダッシュボード』→『更新』で更新の有無と互換性を確かめます。プラグインごとの最終更新日と対応する版を見る場所は、公式ディレクトリのページか、プラグイン一覧の『詳細を表示』です。

サイトヘルスで『致命的な問題』を確認する

サイトヘルスの『ステータス』タブは、結果を『致命的な問題』『おすすめの改善』『テスト通過』に分けて表示します。脆弱性の点検で見るのは、『バックグラウンド更新が想定通りに動作していません』『更新可能なプラグインがあります』『停止中のプラグインを削除してください』の3つです。1つ目が出ていれば、セキュリティ修正の自動更新が届いていない可能性があります。

『情報』タブには、本体の版のほか、有効と停止中それぞれのプラグインとテーマの版、自動更新の設定が並びます。『サイト情報をクリップボードにコピー』で全項目を文字で取り出せるので、点検記録に貼っておくと次回の比較に便利です。

更新画面で、更新の有無と互換性を確認する

『ダッシュボード』→『更新』には、本体、プラグイン、テーマ、翻訳の更新がまとめて表示されます。更新が出ているプラグインの行に出るのは、『WordPress 7.1.3 との互換性: はい (作成者による評価)』か『未確認』の表示です。この評価は作成者の自己申告で、動作の保証ではありません。

『この更新は現在使用中の PHP のバージョンでは動作しません』と出た更新は、PHPを上げるまで適用できません。修正版が出ていても入らないため、PHPの更新を先に計画します。

プラグインの最終更新日と、対応する最新バージョンを見る

公式ディレクトリのプラグインページには、『最終更新日』『有効インストール数』『WordPress バージョン』『検証済み最新バージョン』が並びます。管理画面の『詳細を表示』でも、同じ情報が『最終更新:』『対応する最新バージョン:』として出ます。検証済みの版が現在の本体(7.1.3)から大きく遅れているものは、保守が続いているかを確かめる対象です。

公式ディレクトリは、最新3回のメジャーリリースで検証されていないプラグインに黄色の警告を、閉鎖されたプラグインに赤色の警告を表示します。赤色の警告は『このプラグインは(日付)にクローズし、もうダウンロードできません』という形です。閉鎖から60日後には、セキュリティ上の問題(Security Issue)などの理由も示されます。

使っていないプラグインとテーマを洗い出す

『プラグイン』→『インストール済みプラグイン』の『停止中』で、使っていないプラグインを絞り込みます。サイトヘルスは『停止中のプラグインは攻撃者の標的になります』と表示し、使う予定が無ければ削除を勧めています。停止はプラグインを動かさないだけで、ファイルはサーバーに残るからです。

テーマも、停止中のものを削除します。ただしサイトヘルスは、有効なテーマ、その親テーマ、デフォルトテーマ1つは残すよう案内しています。使っているテーマに問題が起きたとき、WordPressが代わりに使うのがデフォルトテーマです。

• サイトヘルスに『バックグラウンド更新が想定通りに動作していません』が出ていない
• 『ダッシュボード』→『更新』に、適用していない更新が残っていない
• 停止中のプラグインが無く、停止中のテーマは親テーマとデフォルトテーマだけ
• 最新3回のメジャーリリースで検証されていないプラグインが無い
• 公式ディレクトリで閉鎖されたプラグインが無い
• 管理者権限のユーザーが、現在の担当者だけになっている

WP-CLIで、版と配布状況を一覧にする

サーバーにSSHで入れるなら、WP-CLIで本体、プラグイン、テーマの版と更新の有無に加え、公式ディレクトリでの閉鎖と最終更新日まで一覧にできます。出力をそのまま点検記録に残せるのも利点です。

# 本体の版と、本体の更新の有無
wp core version
wp core check-update

# 更新が出ているプラグインとテーマ
wp plugin list --update=available
wp theme list --update=available

# 停止中のプラグインとテーマ(削除の候補)
wp plugin list --status=inactive
wp theme list --status=inactive

『wp core check-update』は、本体が最新なら『Success: WordPress is at the latest version.』と表示します。更新があれば、版と種類(major、minor)を表で返します。次のコマンドは、公式ディレクトリでの状態と最終更新日をプラグインごとに並べるものです。

wp plugin list --fields=name,status,version,update,wporg_status,wporg_last_updated

# 例(表示を簡略化。名前と日付は説明用)
| name         | status   | version | update    | wporg_status | wporg_last_updated |
| example-form | active   | 3.2.1   | available | active       | 2026-09-30         |
| old-slider   | inactive | 1.4.0   | none      | closed       | 2023-05-11         |
| custom-tool  | active   | 2.0.5   | none      |              |                    |

公開の脆弱性情報と照合する: JVN iPedia、NVD、CVE、公式発表

版の一覧ができたら、本体はWordPress公式のセキュリティ発表で、プラグインとテーマはJVN iPediaやNVDで製品名を検索して照合します。読むべき項目は、影響を受ける版の範囲、修正版の番号、悪用が確認されているかの3つです。

情報源の使い分け

JVN iPediaは、国内の開発者が公開した情報、JVNで公表した情報、米国NISTのNVDの情報を集約し、日本語に翻訳したデータベースです。IPAの登録状況の報告によると、2007年4月25日に公開が始まり、2026年第1四半期までの登録は累計277,036件にのぼります。NVDは米国政府の脆弱性管理データのリポジトリで、CVEは、公開された脆弱性を特定、定義して目録にまとめるCVEプログラムの識別番号です。

影響を受ける版と修正版を照らし合わせる

照合の要は、自分の版が影響を受ける版の範囲に入るかどうかです。範囲は『以上』と『未満』で書かれることが多く、『未満』の側に書かれた版が修正版にあたります。

たとえばIPAの注意喚起は、CVE-2026-63030の影響を受ける版を6.9.0から6.9.4と7.0.0から7.0.1とし、修正版を6.9.5と7.0.2としています。NVDのデータでも、6.9以上6.9.5未満と、7.0以上7.0.2未満が影響範囲です。6.9.4のサイトは該当し、6.9.5に上げれば該当しなくなります。

1. 版を書き出す本体、プラグイン、テーマの名前と版を一覧にします。前の節のWP-CLIの出力をそのまま使えます。
2. 製品名で検索するJVN iPediaとNVDでプラグイン名やテーマ名を検索し、本体はWordPress公式のセキュリティ発表を読みます。
3. 範囲と照らす影響を受ける版の範囲に自分の版が入るかを確かめ、入っていれば修正版の番号を控えます。
4. 優先順位を決めるログインせずに狙えるものと、悪用が確認されているものから先に、更新の予定を入れます。

深刻度は点数だけでなく、攻撃の条件で読む

深刻度の表記は、評価する側によって変わります。9月22日の7.1.2で直った脆弱性(CVE-2026-87902)は、WordPress公式の発表では『critical』です。一方、CVSS v3の基本値は8.1で、JVN iPediaの表示は『重要』でした。

点数より先に読むのは、攻撃の条件です。JVN iPediaの『攻撃に必要な特権レベル: 不要』は、ログインせずに狙えることを示します。『参考情報』に米国CISAの『Known Exploited Vulnerabilities Catalog』が載っていれば、実際の悪用が確認された脆弱性です。

CVE-2026-87902は公表から3日後の9月25日に、CVE-2026-63030は公表から4日後の7月21日に、このカタログへ追加されました。2件とも、公表から悪用の確認まで数日しかありませんでした。

外から見える情報を確認する: 版の露出と公開ファイル

外からの確認では、自分のサイトに対して、第三者が取得できる版の情報と公開ファイルを調べます。版を隠しても脆弱性は直りませんが、何が見えているかを知ると、点検の漏れに気づけます。

標準の設定で版が出る主な場所は、ページの<head>、フィード、CSSやJavaScriptのURLです。<head>には『<meta name="generator" content="WordPress 7.1.3">』が出て、フィードのgeneratorにも同じ版が入ります。版の指定が無いCSSやJavaScriptのURLに付く『?ver=』も、本体の版と同じ値です。

ルートにあるreadme.htmlは、現在の版では版番号そのものを載せていません。ただし、WordPressで作られたサイトであることと動作要件が分かるため、公開しておく理由はありません。プラグインのCSSやJavaScriptに付く番号や同梱の説明ファイルからも、プラグインの版が推定されることがあります。

# 自分が管理するサイトにだけ実行します
# トップページとフィードに、版が出ていないか
curl -s https://example.com/ | grep -io '<meta name="generator"[^>]*>'
curl -s https://example.com/feed/ | grep -io '<generator>[^<]*</generator>'

# readme.html が公開されているか(200なら公開、404なら非公開)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/readme.html

# 例(出力)
<meta name="generator" content="WordPress 7.1.3">
<generator>https://wordpress.org/?v=7.1.3</generator>
200

当社の無料のWebサイトのセキュリティチェックは、URLを入れるだけで、本体、プラグイン、テーマの版と既知の脆弱性、配布終了の有無を確かめます。readme.htmlやxmlrpc.phpの公開、REST APIでユーザー名の一覧が取れるかも、調べる対象です。診断は公開ページの取得やDNSの照会に限られ、攻撃の通信は送らないため、ログイン後の画面や管理画面の内側は対象外です。

wp-config.phpのバックアップや.git、.envなど、公開してはいけないファイルの確認方法は.gitや.envが公開されていないか確認する方法で扱っています。フォルダの中身が一覧で見えるディレクトリリスティングも、アップロード用のフォルダ(wp-content/uploads)で、サーバーの設定によって起きることがあります。

更新の前の準備と、更新の順序

更新の基本は、バックアップを取って戻せることを確かめ、検証環境で試してから、本番で1つずつ行うことです。公式のUpgrading WordPressも、手動更新の最初の3段階を、データベースのバックアップ、全ファイルのバックアップ、バックアップの検証としています。

バックアップは戻せることまで確かめる

バックアップに要るのは、データベースとファイル(少なくともwp-contentとwp-config.php)の両方です。取っただけで終えず、検証環境へ実際に戻し、ページが表示されるかまで確かめます。サーバー会社のバックアップを使う場合は、保存期間と戻し方を事前に確認しておきます。

# 例: WordPressの設置フォルダで実行し、公開フォルダの外(~/backups)へ書き出す
mkdir -p ~/backups
wp db export ~/backups/db-20261012.sql
tar -czf ~/backups/files-20261012.tar.gz wp-content wp-config.php

バックアップのファイルを公開フォルダの中に置くのは危険です。外から取得されるおそれがあり、データベースには会員情報や問い合わせの内容も含まれます。保存先と消す時期まで決めておきます。

検証環境で先に試す

検証環境(ステージング)は、本番と同じ版の本体、プラグイン、テーマ、PHPを揃えた複製です。ここで更新し、表示、問い合わせフォーム、会員機能、決済を操作してから本番に移ります。検証環境にはベーシック認証などをかけ、検索結果に載らないようにします。

使い終えた検証環境や旧サイトも、点検の対象です。IPAは、不要になったページを残すと管理が及ばず、脆弱性が見つかったときに影響を受けるおそれがあるとして、不要になった時点で非公開にするよう勧めています。

本体、プラグイン、テーマの順に1つずつ更新する

公式の手動更新の手順は、本体のファイルを入れ替えたあとに、更新されたプラグインとテーマを入れる流れです。本体の大型更新の前には、更新画面の互換性の表示で、各プラグインが新しい版に対応しているかを確かめます。脆弱性が公表されているものがあれば、その更新が最優先です。

まとめて更新すると、不具合が出たときに原因を特定できません。1つ更新するごとに表示を確かめれば、原因をその場で切り分けられます。

1. 更新の内容を読む変更履歴とセキュリティ発表で、修正の内容と対象の版を確かめます。
2. バックアップを取るデータベースとファイルを公開フォルダの外へ保存し、戻せることを確かめます。
3. 検証環境で試す同じ更新を検証環境で行い、主要な画面と機能を操作します。
4. 本番を1つずつ更新するアクセスの少ない時間に、本体、プラグイン、テーマの順で進めます。
5. 表示と機能を確かめるトップページ、問い合わせフォーム、会員機能、決済を実際に操作します。
6. 記録を残す日時、対象、更新前後の版、理由(CVE番号など)、確認の結果を書き残します。

修正版が無い、更新できないときの判断

修正版が無いときは、そのプラグインを使い続ける必要があるかと、開発が続いているかの2点で判断します。使わないものは削除し、使うものは『待つ』か『置き換える』かを選びます。

攻撃の兆候を確認する: 不審な管理者、改ざん、見覚えのないファイル

兆候は、ユーザー、ファイル、外からの見え方の3か所で確かめます。WordPress公式のFAQ My site was hackedは、侵害の明確な兆候を挙げています。検索エンジンの警告、サーバー会社によるサイトの停止、許可していないユーザーの作成、目に見える改ざんなどです。

• 見覚えのない管理者アカウントが無い(登録日も見る)
• 本体のファイルが、公式の配布物と一致する
• wp-adminやwp-includesに、本来無いファイルが無い
• .htaccessと、テーマのindex.php、header.php、footer.php、functions.phpに覚えのない変更が無い
• 検索結果やブラウザに、危険なサイトの警告が出ていない
• サーバー会社から、迷惑メールの送信やサイトの停止の連絡が来ていない

# 管理者権限のユーザーと登録日を一覧にする
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 本体のファイルを、公式のチェックサムと照合する
wp core verify-checksums

# 公式ディレクトリのプラグインを、配布物と照合する
wp plugin verify-checksums --all

本体の照合で『File doesn't verify against checksum』と出たファイルは、公式の配布物から書き換えられています。『File should not exist』は、本来無いファイルがあるという意味です。wp-content(テーマ、プラグイン、アップロード)は本体の照合の対象外で、プラグインの照合も公式ディレクトリにあるものに限られます。

侵害が疑われるときの初動

侵害が疑われたら、状況を記録して現状の複製を取り、サーバー会社や保守会社に連絡してから、すべての入口のパスワードを変えます。削除や上書きを急ぐと原因の手がかりが消えるため、順番が大切です。

1. 状況を記録する侵害を疑った理由、気づいた日時とタイムゾーン、直近に入れたプラグインや変更を書き出します。
2. 現状の複製を取る感染していても、掃除の前に今の状態を丸ごと保存します。原因の調査と、作業に失敗したときの比較に使います。
3. 関係先に連絡するサーバー会社と保守会社に連絡します。共用サーバーでは、被害がほかのサイトに及んでいることもあります。
4. 入口をすべて閉じる全ユーザーのパスワードと、FTPやSFTP、サーバーの管理画面、データベースのパスワードを変えます。wp-config.phpの認証用ユニークキーを入れ替えると、ログイン中の全員が締め出されます。
5. 本体を同じ版で入れ直すwp-adminとwp-includesを、同じ版の公式の配布物で置き換えます。テーマとプラグインも、公式ディレクトリや提供元から取り直します。
6. 侵入口を塞ぐ原因と考えられるプラグインやテーマを更新するか、削除します。
7. もう一度パスワードを変えるきれいになったことを確かめてから、すべてのパスワードを再度変えます。
8. 影響を確かめて知らせるログで被害の範囲を確かめ、利用者や取引先に影響があれば連絡します。

復旧後は、wp-config.phpに『define( 'DISALLOW_FILE_EDIT', true );』を書きます。管理画面からテーマとプラグインのファイルを編集できなくなり、管理者アカウントを乗っ取られても、コードを書き換えられる被害を抑えられます。

自社で切り分けるのが難しい場合は、IPAの情報セキュリティ安心相談窓口や、JPCERT/CCのインシデント対応依頼が公的な相談先です。診断や復旧の進め方は、当社のお問い合わせ窓口でも相談を受け付けています。

自動更新の使い分け

本体のセキュリティ修正(マイナー版)の自動更新は止めずに使い、プラグインとテーマは影響の大きさで自動と手動を分けます。自動に任せた部分も、版が上がったかの点検は欠かせません。

WordPress 5.6以降の新規インストールでは、Gitなどで管理している場合を除き、本体はマイナー版と大型更新の両方が既定で自動です。5.6より前に入れたサイトは、設定を変えていなければマイナー版と翻訳だけが自動になっています。プラグインとテーマの自動更新は5.5で加わった機能で、一覧の『自動更新を有効化』から個別に切り替える形です。

// wp-config.php の例1: 本体の自動更新をマイナー版だけにする
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// 例2: 大型更新も含めて自動にする(例1とどちらか一方だけを書く)
// define( 'WP_AUTO_UPDATE_CORE', true );

自動更新は既定で1日2回実行され、結果は管理者にメールで届きます。ただしIPAは、環境や設定によって自動更新が有効でなかったり、失敗したりする可能性を挙げ、管理画面で版が上がったかを確かめるよう求めています。

点検の頻度、担当、更新の記録を決める

点検を続けるこつは、頻度ごとに作業を分け、担当者を決めることです。IPAも、自組織で使うソフトウェアを把握し、脆弱性がある版でないかを定期的に確認するよう求めています。

担当は、主担当と代理の2人を決めます。サーバー会社や制作会社に保守を任せている場合は、IPAが勧めるとおり事業者の作業範囲を確かめ、足りない部分を自社で受け持ちます。たとえば本体の自動更新はサーバー会社、プラグインの更新は制作会社、点検記録の確認は自社、という分け方です。

更新の記録は、作業ごとに次の項目を残す形で十分です。記録があれば、不具合や侵害が起きたときに、いつ何を変えたかを後からたどれます。

• 日時と作業者
• 対象(本体、プラグイン名、テーマ名)
• 更新前と更新後の版
• 更新の理由(CVE番号、注意喚起のURL)
• 確かめた画面と機能、その結果
• 問題が出たときの対応(戻した、保留した、など)

月1回の外からの確認に使える道具の1つが、当社の無料のセキュリティチェックです。WordPress以外も含めたサイト全体の点検項目は、Webサイトのセキュリティチェック項目30選にまとめています。

WordPressの脆弱性確認でよくある質問

関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面 関連記事.gitや.envが公開されていないか確認する方法と、見つかった時の対処 関連記事セキュリティヘッダーの設定方法｜HSTS、CSPの設定例つき

The post WordPressの脆弱性を確認する方法|本体・プラグインの更新と対処の手順 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

最初に確認する2つのURLと、合否の目安

最初に確かめるのは、自社サイトの /.git/HEAD と /.env です。.git/HEAD はGitの管理フォルダに必ずある1行のファイルで、.gitフォルダが外から見えるかの目印になります。example.com を自社のドメインに置き換え、ターミナルで次のコマンドを実行します。

curl -I https://example.com/.git/HEAD
curl -I https://example.com/.env

# 出力の例(1行目の数字が応答コード)
HTTP/2 404
content-type: text/html

結果は、1行目の数字で次のように読みます。

• 404か403: その場所からは読めません。別の場所と入口は、後の章で確かめます。
• 200: ブラウザで同じURLを開いて中身を見ます。ref: refs/heads/main のような1行や、APP_KEY= などの行が並べば公開中です。
• 301や302: 別のURLへの転送です。curl -IL で転送先までたどり、最後の数字で判断します。

.gitと.envが公開される3つの経路

.gitや.envがURLで読めるのは、Webサーバーが外に配る「公開ディレクトリ」(ドキュメントルート)の中に置かれているからです。公開ディレクトリの外にあるファイルには、URLでは届きません。中に入り込む経路は、主に次の3つです。

1. プロジェクトの直下を公開している: 本来は public などの下位フォルダだけを公開する構成で、プロジェクト全体を公開している状態です。Laravelの公式文書も、プロジェクトの直下から配信すると多くの機密設定ファイルが公開されると注意しています。
2. 公開ディレクトリでGitを使う: 公開ディレクトリの中で git clone や git pull を実行して運用すると、.gitフォルダがそのまま残ります。FTPでプロジェクトのフォルダごとアップロードした時や、WordPressのテーマを開発フォルダのまま置いた時も同じです。
3. バックアップと作業ファイルを残す: 移行作業で作ったzipやデータベースのダンプ、サーバー上の編集で生まれた wp-config.php.bak などの控えが残るケースです。エディターが自動で作る、名前が ~ で終わるファイルや .swp も含みます。

公開されると何が読まれるか

.gitフォルダが読めると、ソースコードと変更の履歴が外に出ます。.envが読めると、書かれた鍵とパスワードがそのまま外に出ます。どちらも、一度読まれた値は相手の手元に残り、後から取り消せません。

.gitフォルダから読まれるもの

• ソースコード一式と変更の履歴。今は消したファイルや、過去に一度コミットしたパスワードも履歴に残ります。
• .git/config に書かれた接続先のURL。Gitの公式文書のとおり、URLには ユーザー名:パスワード@ の形で認証情報を書けます。トークン入りのURLで clone していると、その値も読まれます。
• コミットした人の名前とメールアドレス、ブランチ名など、開発体制の手がかり。

.envから読まれるもの

.envは、フレームワークやアプリが起動時に読み込む設定ファイルです。データベースの接続先とパスワード、決済、メール配信、クラウドのAPIキー、Laravelの APP_KEY のような暗号鍵が並ぶのが一般的です。.envが読まれた時点で、書かれていた値はすべて漏洩したものとして扱います。

.gitと.env以外にも、公開ディレクトリに残りやすいファイルがあります。主な例は次の表のとおりです。

自分のサイトで公開を確認する手順と、見落としやすい場所

確認は、ブラウザで中身を見る方法と、curlで応答コードを並べる方法を組み合わせます。見落としやすいのは、下位フォルダ、別のホスト名、HTTPの側、CDNの裏のサーバーです。

ブラウザで中身を見る

アドレス欄に https://example.com/.git/HEAD を入れて開きます。ref: refs/heads/main のような1行が出れば、.gitフォルダは公開中です。.env で KEY=値 の行が並んだ場合も同じで、表示された値は画面共有やスクリーンショットで広げないようにします。

curlで応答コードとサイズを並べる

候補をまとめて確かめるなら、応答コードと受け取ったバイト数を1行ずつ並べます。サイズがすべて同じなら、同じエラーページかトップページが返っている目安です。macOSやLinuxのターミナル、WindowsならGit BashかWSLで動きます。

for p in /.git/HEAD /.git/config /.env /.env.production /wp-config.php.bak; do
  printf '%-22s ' "$p"
  curl -s -o /dev/null -w '%{http_code} %{size_download}B' "https://example.com$p"
  echo
done

# 出力の例
/.git/HEAD             404 153B
/.env                  404 153B

見落としやすい場所と入口

トップの /.git/HEAD が404でも、別の場所や入口から読めることがあります。次の4つも確かめます。

• 下位フォルダ: /blog/.git/HEAD や /wp-content/themes/テーマ名/.git/HEAD など、Gitで管理していたフォルダの直下。
• 別のホスト名: www の有無、stg. や dev. などの検証環境、使わなくなった旧ドメイン。
• HTTPとHTTPS: サーバーの設定が別々で、片方だけに拒否の設定が入っていることがあります。
• CDNの裏のサーバー: CDNやWAFで止めていても、元のサーバー(オリジン)にIPアドレスで届くと、その遮断を通りません。

# ホスト名と、HTTP、HTTPSの組み合わせを確かめる
for s in http https; do
  for h in example.com www.example.com; do
    printf '%-5s %-18s ' "$s" "$h"
    curl -s -o /dev/null -w '%{http_code}' "$s://$h/.env"; echo
  done
done

# CDNを通さず、オリジン(例: 203.0.113.10)へ直接確かめる
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/.env | head -n 1

候補を1つずつ試す手間を省くなら、自社の無料ツール「Webサイトのセキュリティチェック」も使えます。対象は、.git、.svn、.env、wp-config.phpの控え、SQLダンプ、バックアップの圧縮ファイルです。ページの取得(GET、HEAD、OPTIONS)だけで確かめ、診断できるのは自社または管理権限のあるサイトに限られます。

200、403、404の読み方と、404でも安全と言い切れない理由

応答コードは「その場所から読めるか」を示すだけで、安全の証明ではありません。200は中身を見るまで判断できず、404は確かめた経路の結果でしかないからです。

表の「ソフト404」はGoogleの用語で、存在しないページにも200を返す状態を指します。迷った時は、次の図の順にたどります。

404でも安全と言い切れない4つの理由

1. 確かめた経路の結果でしかない: 前の章の下位フォルダ、別のホスト名、HTTP、オリジンは、それぞれ別に確かめる必要があります。
2. 過去の公開は分からない: 今日の404は、昨日まで読めなかった証明になりません。過去の公開は、アクセスログで確かめます。
3. HEADとGETで応答が違う場合がある: HTTPの仕様(RFC 9110)は、HEADにGETと同じヘッダーを返すことを『SHOULD』(推奨)にとどめています。curl -I が404や405でも、-I を外したGETでも確かめます。
4. 拒否が一部のファイルにしか効いていない: 設定の書き方によっては、/.env は403でも /.git/HEAD は200のまま、という状態が起きます。実例は、後の章のApacheの表に載せています。

他人のサイトを調べてはいけない理由

他人のサイトに .git や .env があるかを、管理者の許可なく確かめるのはやめてください。見つけた値を使えば法律に触れるおそれがあり、URLを試すこと自体も、相手のログには攻撃の下調べと同じ形で残ります。主な論点は次の3つです。

• 不正アクセス禁止法: 警察庁の解説によると、「不正アクセス行為」には2つの類型があります。他人のIDやパスワードを無断で入力して利用制限を外す行為と、設定ミスなどの不備を突いて制限を免れる行為です。.envで見つけたパスワードでデータベースや管理画面に入れば、これに当たるおそれがあります。
• 取得、保管、提供: 不正アクセスに使う目的で他人のIDやパスワードを取得、保管することや、正当な理由なく人に渡すことも禁じられています。同じ解説は、検索中にたまたま表示された場合は、取得の罪に当たらないとも説明しています。
• 試し方と負荷: IPAなどが定める情報セキュリティ早期警戒パートナーシップガイドラインは、URLの数字を積極的に多数変えて試す行為を例に挙げています。こうした行為は、制限を免れる目的とみなされる可能性があるという説明です。故意にサーバーの性能を落とす行為は、業務妨害罪に触れる可能性があるとも述べています。

同ガイドラインは、IPAが届出を受け付けても、発見の方法についての法的な責任は免除されないと明記しています。善意の確認であっても、許可の無い調査は自分を守る根拠になりません。

漏洩が見つかった時の対処: 優先順位つきの7手順

公開を見つけたら、すでに読まれた前提で、公開の停止、鍵の作り直し、ログの調査の順に進めます。1と2を最優先で終え、調査と連絡はその後に回します。

1. 公開を止めるファイルやフォルダを公開ディレクトリの外へ移すか、後の章の拒否の設定を入れ、URLが404か403になったことを確かめます。消す前に、書かれていた値の一覧と、ファイルの更新日時を控えます。アクセスログは調査に使うので、消さずに残してください。
2. 鍵とパスワードを失効させ、作り直す書かれていた値は、使っていないものも含めてすべて対象です。.gitが公開されていた場合は、履歴の全期間に一度でもコミットされた値まで含めます。新しい値は、公開ディレクトリの外にある設定に入れてから切り替えます。
3. アクセスログで読まれたかを調べる該当URLに、いつ、どのIPアドレスへ、何バイトを返したかを確かめます。コマンドの例は、この手順の下に載せています。
4. 不正利用の跡を調べるデータベースへの見知らぬ接続や操作、管理画面の不明なアカウント、クラウドやAPIの請求額、メールの送信履歴を確かめます。
5. Git履歴から取り除くリポジトリに秘密の値が入っていた場合は、履歴からも取り除きます。手順と注意点は次の章で説明します。
6. 関係者に連絡する社内の責任者、制作や保守の委託先、APIの提供元に、何が、いつから公開されていたかを伝えます。個人情報を扱うデータベースに入られたおそれがあれば、個人情報保護委員会への報告が必要かを確かめます。
7. 再発防止を入れ、もう一度確かめる後の章の配置と設定を入れたあと、最初の章のcurlで、すべての場所と入口が404か403になることを確かめます。

手順2で作り直す主な値と、切り替える時の注意は次のとおりです。

Laravelは、旧鍵を APP_PREVIOUS_KEYS に並べると、旧鍵で暗号化した値も復号できる仕組みを持っています。漏洩した鍵をここに残すと、その鍵で作られた値も受け付け続けるため、保存データを新しい鍵で暗号化し直したら外します。

手順3のログ確認では、該当URLへの要求のうち、200で返したものを抜き出します。ログの場所は、Nginxなら /var/log/nginx/、Apacheなら /var/log/apache2/ や /var/log/httpd/ が一般的です。レンタルサーバーでは、管理画面から取り出したログに同じ検索をかけます。

# 200で返した .git と .env への要求(日時、IPアドレス、URL、返したバイト数)
zgrep -hE '/[.](git|env)' /var/log/nginx/access.log* |
  awk '$9 == 200 {print $4, $1, $7, $10}'

# IPアドレスごとの件数
zgrep -hE '/[.](git|env)' /var/log/nginx/access.log* |
  awk '$9 == 200 {print $1}' | sort | uniq -c | sort -rn

標準のログ形式(combined)では、9番目の欄が応答コード、10番目が返したバイト数です。バイト数がトップページやエラーページと同じなら、ファイルの中身は渡っていない可能性が高いと読めます。見知らぬIPアドレスの国や組織は、自社の無料ツール「IPアドレスから位置を調べるツール」でも調べられますが、結果は目安です。

Git履歴から消すだけでは足りない理由と、消す手順

Git履歴から秘密の値を消しても、すでに複製されたものは消えません。公開されていた.gitを取得した人の手元、開発者のクローン、フォークには古い履歴が残ります。GitHubの公式文書も、秘密の値は最初に失効させるか作り直すべきだとしています。

そのうえで履歴から取り除くのは、古い値の再利用や、別の人による再公開を防ぐためです。GitHubが示す手順の要点は、新しいクローンで書き換えて、まとめて送り直すことです。

# 1. 作業用に、新しくクローンする
git clone https://github.com/組織名/リポジトリ名.git
cd リポジトリ名

# 2. 全履歴から .env を取り除く(git-filter-repo 2.47以降)
git filter-repo --sensitive-data-removal --invert-paths --path .env

# 3. 書き換えた履歴を送る(共同作業者へ事前に知らせる)
git push --force --mirror origin

# 4. 今後は追跡しないよう .gitignore に加える
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Ignore .env"
git push origin main

書き換えのあと、古いクローンを持つ人はクローンし直します。GitHubの文書は、古い履歴から作ったブランチを、mergeではなくrebaseするよう求めています。GitHubの画面に残るキャッシュや、プルリクエストが参照する古いコミットの削除は、GitHubサポートへの依頼が必要です。

再発防止の基本: 公開ディレクトリの外に置く

根本の対策は、秘密の値と管理用のフォルダを、公開ディレクトリの外に置く配置にすることです。サーバーの拒否設定は、移行や設定の書き換えで消えることがあるため、2段目の守りと考えます。

• Laravelなど: 公開ディレクトリを public に設定し、.env や .git はその1つ上に置きます。
• WordPress: 公式の手引きのとおり、wp-config.php はインストール先の1つ上の階層へ移しても動きます。
• バックアップ: 圧縮ファイルやダンプは、公開ディレクトリの外か別の保管場所に置き、作業後に消すことを手順書に入れます。
• 公開先を変えられないサーバー: サーバー会社の案内で、公開フォルダの外に置ける場所があるかを確かめます。

サーバー設定で拒否する: Apache、Nginx、WordPressの例

配置を直すまでの応急処置と、置き忘れへの備えとして、ドットで始まるファイルとフォルダ、バックアップのような名前を拒否します。ここでの設定例と表の応答は、nginx 1.30.5とApache 2.4.69での動作確認に基づきます。

Apache(.htaccess)

公開ディレクトリの .htaccess の先頭に、次の2行を書きます。正規表現の [.] は、ドットそのものを表す書き方です。

# ドットで始まるファイルとフォルダを 404 にする(.well-known は除く)
RedirectMatch 404 /[.](?!well-known/)
# バックアップや作業用のファイルを 404 にする
RedirectMatch 404 (?i)([.](bak|old|orig|save|swp|sql)|~)$

.well-known を除くのは、SSL/TLS証明書の自動更新(Let’s Encryptなど)や security.txt がこの場所を使うためです。除外を忘れると証明書の更新が失敗するので、更新の状況は「SSL/TLS証明書のチェック方法」の手順で確かめます。サイトでzipなどを配布していなければ、2行目に zip や gz を足せます。

表の「FilesMatchだけ」は、<FilesMatch "^[.]"> と Require all denied の組み合わせです。Apacheの公式文書のとおり、FilesMatchはファイル名(パスの最後の部分)だけを見ます。そのため /.git/HEAD は HEAD という名前で判定され、拒否されません。

.htaccessは、サーバーが上書きを許している時だけ効く仕組みです。許可が無いとエラーも出ずに何も効かないため、書いた後は /.env が404になるかをcurlで確かめます。

一覧表示を止める Options -Indexes は、上書きの許可が無いと、書いただけでサイト全体が500エラーになります。追加したら、すぐにトップページを開いて確かめてください。

Nginx

Nginxは.htaccessを読まないため、サーバー設定の server ブロックに書きます。書いたら nginx -t で構文を確かめてから、設定を再読み込みします。

# ほかの正規表現の location より前に書く
location ~ /[.](?!well-known/) {
    return 404;
}
location ~* ([.](bak|old|orig|save|swp|sql)|~)$ {
    return 404;
}

# ^~ を付けた location の中では上の規則が効かないため、中にも書く
location ^~ /assets/ {
    location ~ /[.] {
        return 404;
    }
}

Nginxの公式文書のとおり、正規表現のlocationは書いた順に調べられ、最初に当てはまったものが使われます。静的ファイル用の正規表現を先に書くと、/.notes.txt のようなファイルがそちらで配られます。また、^~ を付けたlocationの下では正規表現が調べられないため、例の /assets/.env は中に拒否を書くまで200のままです。

WordPress

Apacheで動くWordPressでは、上の2行に wp-config.php の拒否を加えたものを、.htaccess の先頭に置く形が基本です。WordPressの公式の手引きによると、# BEGIN WordPress と # END WordPress の間は、WordPressが書き換えることがあります。そのため、追加する行はこの範囲の外に書きます。

# 既存の「# BEGIN WordPress」より上に、次の行を足す
RedirectMatch 404 /[.](?!well-known/)
RedirectMatch 404 (?i)([.](bak|old|orig|save|swp|sql)|~)$
<Files "wp-config.php">
    Require all denied
</Files>

# (この下に、WordPressが管理する「# BEGIN WordPress」から
#  「# END WordPress」までが続く。その間には書き足さない)

あわせて、wp-config.php の WP_DEBUG_LOG の値も確認が必要です。true にすると、エラーは既定で wp-content/debug.log に書かれ、公開ディレクトリの中に残ります。本体やプラグインの更新状況も合わせて点検するなら、「WordPressの脆弱性を確認する方法」の手順が使えます。

サーバー設定を開く機会に、セキュリティヘッダーも一緒に見直すと、作業が1回で済みます。設定例は「セキュリティヘッダーの設定方法」にまとめています。

デプロイ手順と.gitignoreで、混入を防ぐ

.gitや.envを公開先へ持ち込まない手順にすれば、拒否の設定に頼る場面が減ります。要点は、公開するファイルだけを、決まった手順で送ることです。

• 送るのはビルド後の成果物だけ: dist や public など、公開用のフォルダだけを送ります。git archive で作るアーカイブには、.gitフォルダが入りません。
• 公開ディレクトリでcloneしない: Gitの操作は公開ディレクトリの外で行い、成果物だけを配置します。
• FTPでフォルダごと上げない: 送る前に、ドットで始まる隠しファイルを表示して、中身を確かめます。
• 検証環境も同じ扱いにする: stg. などの検証環境は、IP制限やBasic認証で関係者だけに絞ります。

.gitignoreは、秘密の値をリポジトリに入れないための設定です。ただしGitの公式文書のとおり、すでに追跡しているファイルには効かないため、git rm --cached で追跡を外してから使います。

# .gitignore の例(.env.example だけは共有する)
.env
.env.*
!.env.example
*.log
*.sql
*.bak

# すでに追跡している .env を外す(手元のファイルは残る)
git rm --cached .env

デプロイ前に自動で止める

人の注意に頼らず、公開用のフォルダに置いてはいけないファイルがあれば、デプロイを止める確認を手順に組み込みます。次の例は、見つかった時に終了コード1で止まるため、CIの1工程として使えます。

# 公開するフォルダ(ここでは dist)に、置いてはいけないファイルが無いか確かめる
found=$(find dist -name '.git' -o -name '.env*' -o -name '*.sql' -o -name '*.bak')
if [ -n "$found" ]; then
  echo "公開してはいけないファイルがあります:"
  echo "$found"
  exit 1
fi

コミットの段階では、OSSのGitleaksなど、パスワードやAPIキーの形の文字列を見つける道具を、コミット前の確認(pre-commit)に入れられます。GitHubの公開リポジトリでは、シークレットスキャンが無料で自動的に動く仕組みです。公開後は、同じURLを外から定期的に確かめる処理をサーバー監視の項目に加えると、設定の巻き戻りに気づけます。

公開前と更新後のチェックリスト

• 公開ディレクトリが public などの公開用フォルダだけを指している
• /.git/HEAD、/.env、/wp-config.php.bak が、すべてのホスト名とHTTP、HTTPSで404か403になる
• CDNを使う場合、オリジンへ直接確かめても同じ結果になる
• 拒否の設定を入れた後も、トップページと /.well-known/ の下が表示される
• 公開ディレクトリに、zip、SQLダンプ、debug.log、phpinfoのページが残っていない
• .gitignoreに .env が入り、git ls-files の一覧に .env が出てこない
• デプロイの手順に、置いてはいけないファイルの確認が入っている

サーバーの入れ替え、デプロイ方法の変更、制作会社の交代の後が、このリストを最初からやり直す時期です。公開ファイル以外の点検項目は、「Webサイトのセキュリティチェック項目30選」にまとめています。無料の簡易チェックで分かる範囲と、専門の診断が要る場面の違いは、「簡易チェックと脆弱性診断の違い」で説明しています。

よくある質問

関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面関連記事WordPressの脆弱性を確認する方法｜本体、プラグインの更新と対処の手順関連記事セキュリティヘッダーの設定方法｜HSTS、CSPの設定例つき

The post .gitや.envが公開されていないか確認する方法と、見つかった時の対処 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

SSL/TLS証明書で確認する6項目と合格の基準

確認する項目は、有効期限、ホスト名(SAN)、チェーン、TLSの版、暗号スイート、HTTPSへの転送の6つです。項目ごとに合格の基準を先に決めておくと、ブラウザやコマンドの結果をそのまま判定に使えます。

期限の基準を『残り3分の1』としたのは、Let’s EncryptとCertbot(4.0以降)の更新時期に合わせたためです。200日の証明書なら残り約66日、90日なら残り30日が目安です。

6項目をまとめて外から確かめるなら、当社の無料ツール『Webサイトのセキュリティチェック』も使えます。URLを入れるだけで、証明書の期限、ホスト名、中間証明書の不足、古いTLSや弱い暗号、HTTPSへの転送などを確認できます(登録不要)。

外から見える設定を受動的に調べる検査のため、脆弱性診断の代わりにはなりません。役割の違いは『簡易チェックと脆弱性診断の違い』に、証明書以外の点検項目は『Webサイトのセキュリティチェック項目30選』にまとめています。

証明書のチェーンの仕組み(ルート、中間、サーバー証明書)

ブラウザは、サーバー証明書から中間証明書をたどり、端末に入っているルート証明書に行き着けたときだけ証明書を信頼します。サーバーが送るのはサーバー証明書と中間証明書で、ルート証明書は送らなくてかまいません(TLS 1.3の仕様、RFC 8446)。

ルート証明書は認証局の大本で、OSやブラウザの信頼ストアに最初から入っています。中間証明書はルート証明書の署名を受けた認証局の証明書で、サーバー証明書に署名する役割です。サーバー証明書はドメインごとに発行され、SAN(サブジェクトの代替名)に対象のホスト名が並びます。

Certbotで取得した場合は、サーバー証明書と中間証明書をこの順につないだ fullchain.pem をWebサーバーに設定します。

PCのブラウザで開けても、チェーンの欠落は隠れる

中間証明書を送っていないサーバーでも、PCのブラウザでは警告が出ないことがあります。Chromeは足りない中間証明書を証明書内の情報(AIA)から取りに行き、Firefoxは信頼された中間証明書をあらかじめ取り込んでいるためです。

一方、curlやOpenSSLで通信するプログラムは、足りない中間証明書を自動では補いません。同じ設定でも、外部システムからのAPI接続や監視ツールだけが『unable to get local issuer certificate』で失敗します。

ブラウザでSSL証明書を確認する手順(Chrome、Edge、Firefox、Safari)

ブラウザでは、アドレスバー左端のアイコンから証明書の画面を開き、発行先、発行元、有効期間を確かめます。ChromeとEdgeは同じ形式の画面で、Firefoxはチェーンの証明書をタブで切り替えて表示します。

Chromeで証明書を開く手順

1. アイコンを開くアドレスバー左端の『サイト情報を表示』アイコンをクリックします。
2. 接続の情報を開く『この接続は保護されています』をクリックします。
3. 証明書の画面を開く『証明書は有効です』をクリックすると、証明書の画面が開きます。
4. 期限と発行元を読む『全般』タブで、発行先、発行元、有効期間(発行日と有効期限)を確かめます。
5. チェーンとSANを読む『詳細』タブの『証明書の階層』でチェーンを、『証明書のフィールド』の『証明書のサブジェクトの代替名』でSANを確かめます。

Edge、Firefox、Safariでの開き方

デベロッパーツールでTLSの版と暗号を見る

TLSの版と暗号は、Chromeのデベロッパーツールの『セキュリティ』パネルで確かめられます。デベロッパーツールを開いてCtrl+Shift+P(MacはCommand+Shift+P)を押し、『セキュリティを表示』と入力すると移動できます。

『接続』の欄には、TLSの版(例: TLS 1.3)、鍵交換(例: X25519MLKEM768)、暗号(例: AES_128_GCM)が並びます。古い版や弱い方式を使っていると『廃止された接続設定』と表示されるので、見直しの目安になります。

opensslでSSL証明書の有効期限、発行者、SANを確認する

openssl s_client でサーバーから証明書を受け取り、openssl x509 で期限、発行者、SANを表示します。Linuxのサーバー上のほか、WindowsではGit for Windowsに付属するGit Bashでも同じコマンドが使えます。

openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

出力の例です(値は説明用です)。

subject=CN=example.com
issuer=C=JP, O=Example Trust, CN=Example Intermediate CA R1
notBefore=Sep 20 00:00:00 2026 GMT
notAfter=Dec 18 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

openssl x509の出力の読み方

• subject: 証明書の主体者です。CN=の値は参考で、名前の照合にはSANが使われます(RFC 9525)。
• issuer: この証明書に署名した中間認証局です。
• notBefore、notAfter: 有効期間の始まりと終わりです。GMT表記なので、日本時間は9時間足します(例の期限は日本時間の2026年12月19日8時59分59秒)。
• X509v3 Subject Alternative Name: 証明書が有効なホスト名の一覧です。wwwの有無やサブドメインを含め、使う名前がすべて入っているかを見ます。

特定の名前が含まれるかは、OpenSSL 3系なら -checkhost で判定できます。サーバー上の証明書ファイルは、-checkend に秒数を渡すと、期限までの残りがそれより短いかを終了コードで返します。

openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -checkhost www.example.com
# 例: Hostname www.example.com does match certificate

# 残り30日(2,592,000秒)を切っていれば終了コード1(Certificate will expire)
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -checkend 2592000

opensslでチェーンの欠落と名前の不一致を判定する

チェーンは、s_client が表示する証明書の一覧と、最後の『Verify return code』で判定します。0 (ok) なら合格で、中間証明書が欠けていると21になります。

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com </dev/null 2>/dev/null \
  | grep -E '^ [0-9] s:|^   i:|^Verify return code'

出力の例です。正常なときは、0番のサーバー証明書の発行者(i:)と、1番の中間証明書の主体者(s:)が同じ名前でつながります。中間証明書が欠けていると、1番の行が無く、21が返ります。

# 正常な例
 0 s:CN=example.com
   i:C=JP, O=Example Trust, CN=Example Intermediate CA R1
 1 s:C=JP, O=Example Trust, CN=Example Intermediate CA R1
   i:C=JP, O=Example Trust, CN=Example Root CA
Verify return code: 0 (ok)

# 中間証明書が欠けている例
 0 s:CN=example.com
   i:C=JP, O=Example Trust, CN=Example Intermediate CA R1
Verify return code: 21 (unable to verify the first certificate)

複数台のサーバーを1台ずつ確かめる

ロードバランサーの配下に複数台があると、1台だけ古い証明書が残ることがあります。-connect に各サーバーのIPアドレス、-servername に本来のホスト名を指定すると、台ごとに確かめられます。

# 203.0.113.10 は説明用のアドレス。台ごとに書き換えて実行する
openssl s_client -connect 203.0.113.10:443 -servername www.example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -enddate

CDNを使っている場合は、利用者に届くCDNの証明書と、CDNが接続する元サーバー(オリジン)の証明書が別物です。両方を監視の対象に入れます。

curl -vで証明書とTLSの状態を確認する

curl -v は、使われたTLSの版と暗号、証明書の期限、SANの照合、検証の結果を1回で表示します。サーバー上での動作確認や、ブラウザと結果を比べたいときに向いています。

curl -sv -o /dev/null https://example.com/ 2>&1 \
  | grep -E 'SSL connection|subject|(start|expire) date|issuer|verified|verify ok'

出力の例です(値は説明用です)。

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / …
*   subject: CN=example.com
*   start date: Sep 20 00:00:00 2026 GMT
*   expire date: Dec 18 23:59:59 2026 GMT
*   issuer: C=JP; O=Example Trust; CN=Example Intermediate CA R1
*   subjectAltName: "example.com" matches cert's "example.com"
* SSL certificate verified via OpenSSL.

『SSL connection using』の行がTLSの版と暗号、『expire date』が期限(GMT)、『subjectAltName』がSANの照合結果です。行末の鍵交換などの表示は、curlとTLSライブラリの組み合わせで変わります。curl 8.5など少し前の版では、最後の行が『SSL certificate verify ok.』と表示されます。

検証に失敗するとcurlは終了コード60で止まり、原因を英語で表示します(主な文言は後の表を参照)。

Windows標準のcurlで確かめるとき

Windowsに標準で入っている curl.exe は、Windowsの暗号機能(Schannel)で通信するため、-v を付けても証明書の期限や発行者が出ません。PowerShellで次のように -w "%{certs}" を使うと、証明書の主体者と期限を書き出せます。

curl.exe -s -o NUL -w "%{certs}" https://example.com/ |
  Select-String '^(Subject|Expire Date):'

最初の2行がサーバー証明書の主体者と期限です(例: Expire Date:2026-12-18 23:59:59 GMT)。チェーンの欠落や名前の照合は、Git for Windowsに付属するopensslで、前の節のコマンドを使って確かめます。

TLSの版と暗号スイートを確かめ、TLS 1.0と1.1を止める

TLS 1.0と1.1はRFC 8996で廃止されており、TLS 1.2と1.3だけを有効にするのが現在の基準です。版を指定して接続を試し、1.2と1.3は接続でき、1.0と1.1は拒否されれば合格です。

# 1.2と1.3は、接続できれば合格(Protocol version の行を見る)
openssl s_client -connect example.com:443 -servername example.com \
  -tls1_2 -brief </dev/null
openssl s_client -connect example.com:443 -servername example.com \
  -tls1_3 -brief </dev/null
# 1.1は、拒否されれば合格(OpenSSL 3系は SECLEVEL=0 の指定が必要)
openssl s_client -connect example.com:443 -servername example.com \
  -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

1.2と1.3で『Protocol version: TLSv1.2』のように表示されれば、その版で接続できています。1.1の試験で『alert protocol version』を含むエラーが出れば、サーバーが古い版を拒否しています。1.0の確認は、-tls1 を指定する同じ手順です。

暗号スイートの考え方

TLS 1.2の暗号スイートは、鍵交換、認証、暗号、ハッシュの組を1つの名前で表します。ECDHE-RSA-AES128-GCM-SHA256 なら、鍵交換がECDHE、認証がRSA、暗号がAES-128-GCM、ハッシュがSHA-256です。

TLS 1.3の暗号スイートは、TLS_AES_128_GCM_SHA256 のように暗号とハッシュだけを表します。鍵交換は『グループ』(X25519など)として別に決まり、どの暗号スイートも認証付き暗号(AEAD)です(RFC 8446)。

TLS 1.2で避けるものは、IETFの推奨文書RFC 9325が示しています。

• RC4: 使用禁止
• 3DES: 実効の強さが128ビットに届かない
• TLS_RSA_WITH_で始まる静的なRSA鍵交換: 前方秘匿性がない
• CBCモード: encrypt_then_mac拡張を使えない場合は避ける
• TLS_DHE_で始まるDHE: TLS 1.2では避ける

Mozilla推奨(Intermediate)に合わせた設定例

サーバー設定の推奨値には、Mozillaの『Server Side TLS』が広く使われてきました。このガイドはMozilla外のコミュニティ作業部会TLSRefへ移り、Mozillaのページは移管先を案内しています。

2026年4月の6.0版で、古い端末向けの『Old』は廃止されました。一般の公開サイト向けの『Intermediate』の推奨値は次のとおりです。

# nginx: 次の3行は http ブロックに置く
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE+AESGCM:ECDHE+CHACHA20:!PSK;
ssl_prefer_server_ciphers off;

# HTTPSの server ブロックに置く
add_header Strict-Transport-Security "max-age=63072000" always;

# Apache(mod_ssl)
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20:!PSK
SSLHonorCipherOrder off
Header always set Strict-Transport-Security "max-age=63072000"

ECDHE+AESGCM:ECDHE+CHACHA20:!PSK は、表のTLS 1.2の6種だけに絞り込む短い書き方です(並び順は異なります)。使う前に、次のコマンドで6種に展開されるかを確かめます。

# TLSv1.2の6行と、TLSv1.3の3行が表示されれば想定どおり
openssl ciphers -v -tls1_2 'ECDHE+AESGCM:ECDHE+CHACHA20:!PSK'

nginxの ssl_protocols は、serverブロックだけに書くと既定のサーバーの値が使われる場合があるため、httpブロックに置きます。鍵交換のグループは、OpenSSL 3.5以降なら既定でX25519MLKEM768を優先するので、多くの場合は指定不要です。CDNを使っている場合は、CDN側の最小のTLSバージョンの設定が利用者との通信を決めます。

HTTPからHTTPSへの転送、HSTS、混在コンテンツを確かめる

HTTPのURLは301でHTTPSの同じURLへ転送し、HTTPSの応答にはHSTS(Strict-Transport-Security)のヘッダーを付けます。2026年9月公開のChrome 154では、HTTPの接続を開く前に確認を求める警告が既定で有効になりました(Chrome 154のリリースノート)。

Googleの発表では、警告の対象は最近訪れていない公開サイトで、社内などのプライベートなアドレスは対象外です。HTTPSに対応していないホスト名は、サブドメインも含めて警告の対象になります。

# スキームを省くと、curlはHTTP(80番ポート)で接続する
curl -sI example.com | grep -i -E '^HTTP|^location'
curl -sI www.example.com | grep -i -E '^HTTP|^location'
# HTTPSの応答にHSTSが付いているか
curl -sI https://example.com/ | grep -i strict-transport-security

出力の例です。

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/
strict-transport-security: max-age=63072000

合格の基準は、HTTPの各ホスト名が301(恒久的な転送)でHTTPSへ移ることと、HTTPSの応答にHSTSがあることです。HSTSはセキュリティヘッダーの1つで、設定の手順は『セキュリティヘッダーの設定方法』で詳しく扱っています。

HSTSを入れると、証明書のエラーは回避できなくなる

HSTSを記憶したブラウザは、max-ageの期間中に証明書のエラーが起きると、警告を回避して進む選択肢を出さずに接続を止めます(RFC 6797の8.4節、12.1節)。期限切れがそのまま全面的な停止になるため、HSTSは自動更新と監視が動いてから設定します。

HSTSのヘッダーは、HTTPSの応答でエラーなく受け取ったときだけ有効になり、HTTPの応答に付けてはいけません。max-age=0 を送ると、ブラウザに記憶された設定を消せます。

混在コンテンツを見つけて直す

混在コンテンツは、HTTPSのページの中で画像やスクリプトをHTTPで読み込んでいる状態です。現在のブラウザは、画像、音声、動画をHTTPSへ自動で切り替え、スクリプト、CSS、iframeなどはブロックします(MDNの解説)。

見つけるには、デベロッパーツールのコンソールで『Mixed Content』で始まる警告を探し、読み込み元のURLをHTTPSに書き換えます。直しきるまでの応急処置として、CSPの upgrade-insecure-requests でまとめてHTTPSへ切り替える方法もあります。

期限切れのときの影響と、すぐやる対処

期限が切れると、ブラウザは画面全体の警告を出し、API連携やアプリの通信も検証エラーで止まります。まず外から配信中の証明書を確かめ、更新、再読み込み、全台での再確認の順に進めます。

Chromeは『この接続ではプライバシーが保護されません』、Firefoxは『警告: 潜在的なセキュリティリスクあり』という画面に、原因を示すコードを出します。主なコードとcurlの文言は次のとおりです。

ChromeとFirefoxは、中間証明書を補えた場合は3行目の警告を出しません。対処は次の順で進めます。

1. 配信中の証明書を確かめるs_client で notAfter を読み、どのホスト名の、どのサーバーで切れているかを特定します。
2. サーバー上のファイルと比べるファイルの期限が新しいのに配信が古いなら、更新は済んでいて再読み込みが漏れています。
3. 証明書を更新するACMEなら certbot renew などで更新し、有料の証明書は再発行して差し替えます。
4. 設定を確かめて再読み込みするnginx -t で構文を確かめてから、systemctl reload nginx で反映します。
5. 全ホスト名、全台、CDNで確かめるwwwの有無、サブドメイン、各サーバー、CDNの証明書を外から確かめます。
6. 止まった原因を直すcertbot renew --dry-run で失敗を再現し、80番ポートの遮断、DNSの変更、権限の不足などを直します。

# 配信中の証明書の期限
openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -enddate
# サーバー上のファイルの期限(Certbotの例)
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -enddate
# 更新し、構文を確かめてから再読み込み(nginxの例)
sudo certbot renew
sudo nginx -t && sudo systemctl reload nginx

更新したのに古い証明書が出るときの原因は、再読み込みの漏れ、別の台に残った古い証明書、別に管理しているCDNの証明書、設定が別のファイルを指している、のいずれかです。直したあとは、無料の『Webサイトのセキュリティチェック』でも外から結果を確かめられます。原因を切り分けられないときや、更新の自動化を設計し直したいときは、お問い合わせフォームから相談を受け付けています。

自動更新(ACME)と期限の監視を仕組みにする

更新は、ACME(RFC 8555)に対応した認証局とクライアントで自動にし、Webサーバーの再読み込みまでを含めます。そのうえで、自動更新が止まったことに気づけるよう、外から期限を調べる監視を別に置きます。

Certbotは4.0以降、残りが有効期間の3分の1を切った証明書を更新します。--deploy-hook "systemctl reload nginx" を付けると、更新できたときだけ再読み込みが走ります。事前の動作確認に使うのは certbot renew --dry-run です。

更新の時期を認証局から受け取るARI(RFC 9773、2025年6月発行)という仕組みもあり、Let’s Encryptはクライアントでの利用を勧めています。同社は2025年6月4日に期限切れの通知メールを終了したため、通知は自分で用意します。

#!/bin/sh
# 残り日数がしきい値を切った証明書と、検証に失敗したホストを表示する
DAYS=14
for host in example.com www.example.com; do
  cert=$(openssl s_client -connect "$host:443" -servername "$host" \
    -verify_hostname "$host" -verify_return_error </dev/null 2>/dev/null \
    | openssl x509 2>/dev/null)
  if [ -z "$cert" ]; then
    echo "NG $host: 接続、チェーン、名前、期限のいずれかで失敗"
  elif ! echo "$cert" | openssl x509 -noout -checkend $((DAYS * 86400)) >/dev/null; then
    echo "NG $host: 残り${DAYS}日未満"
  else
    echo "OK $host"
  fi
done

しきい値は、自動更新が動く時点より小さく、手で直す時間が残る値にします。90日の証明書は残り30日で自動更新が動くため、14日を切っていれば、自動更新が2週間以上止まっている合図です。cronで毎日動かし、NGの行が出たらチームに通知します。

• 管理しているホスト名(www、サブドメイン、API、メール)と、その証明書の一覧がある
• 更新が自動で、更新後の再読み込みまで含まれている
• certbot renew --dry-run などの更新の試験が成功する
• 外からの期限の監視が毎日動き、通知が複数人に届く
• 2027年3月15日からの100日の上限に合わせ、手作業の更新が残っていない
• サーバーの移転、CDNの導入、DNSの変更のあとに外から確かめる手順がある
• HSTSを入れる前に、上の項目がすべて満たされている

有効期間の短縮の動向(2026年10月時点)

CA/Browser Forumの決議SC-081v3により、公的に信頼されるTLS証明書の最長有効期間は、2026年3月15日以降の発行分で200日になりました。2027年3月15日に100日、2029年3月15日に47日へ短くなります。

決議は2025年4月11日に可決され(提案はApple)、2026年10月4日付のBaseline Requirements 2.3.1版にもこの日程が入っています。日数はnotBeforeからnotAfterまでを含めて数え、1日は86,400秒です。

ドメイン確認の再利用期間は、認証局がドメインの管理権を確かめた結果を使い回せる日数です。2029年には10日になるため、更新のたびにDNSやHTTPでの確認を自動で通せる仕組みが前提になります。

Let’s Encryptの発表によると、既定の90日は2027年2月10日に64日、2028年2月16日に45日へ短くなります。希望者向けの45日の証明書(tlsserverプロファイル)は、2026年5月13日から選べるようになりました。同社は、更新を有効期間の約3分の2の時点で行い、60日ごとのような固定の間隔に頼らないよう求めています。

よくある質問

関連記事

関連記事セキュリティヘッダーの設定方法｜HSTS、CSPの設定例つき 関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面 関連記事WordPressの脆弱性を確認する方法｜本体、プラグインの更新と対処の手順

The post SSL/TLS証明書のチェック方法|有効期限・チェーン・通信方式の確認手順 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 総合デジタルマーケティング企業 エスライン・テクノロジーズ.