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

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

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

最初に確認する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 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

セキュリティヘッダーは影響の小さい順に4段階で入れる

最初に入れるのは、表示が壊れにくいX-Content-Type-OptionsとReferrer-Policyです。次にX-Frame-OptionsとPermissions-Policy、3段階目にHSTS、最後にCSPを入れます。段階を分けておくと、表示や機能が壊れたときに原因のヘッダーを1つに絞り込めます。

セキュリティヘッダーの推奨値は、OWASPのHTTP Headers Cheat Sheetを基準にし、X-Frame-Optionsだけは自サイト内の枠表示を残せる SAMEORIGIN にしています（OWASPは DENY）。段階1と同時に、ServerヘッダーとX-Powered-Byに出る版の表記も消します。

ヘッダーはどこで付き、ブラウザはどう使うか

セキュリティヘッダーは、アプリ（WordPressなど）、Webサーバー、CDNのどこでも付けられ、ブラウザは手元に届いた応答のヘッダーに従って動作を変えます。ブラウザからは、どこで付いたヘッダーかを区別できません。1つのヘッダーを付ける場所を1か所に決めることが、重複と付け漏れを防ぐ近道です。

各ヘッダーの設定値と推奨値

段階1と2の4つは推奨値がほぼ決まっており、自サイトの使い方と突き合わせれば決められます。HSTSとCSPは、後の節の手順で扱います。

X-Content-Type-Options: nosniff

X-Content-Type-Optionsの値は nosniff だけで、Content-TypeがJavaScriptの種類でないスクリプトと、text/cssでないスタイルシートを読み込ませなくします。Chrome 146の場合、text/plainで返したJavaScriptは、nosniffが無いと実行され、付けると止まります。

入れる前に curl -sI https://example.com/main.js で、主なJavaScriptのContent-Typeを調べます。text/javascript などなら合格で、text/plain などならサーバーのMIMEタイプの設定を先に直します。

Referrer-Policy: strict-origin-when-cross-origin

Referrer-Policyは、リンク先や外部の読み込み先へ、元のページのURLをどこまで伝えるかを決めます。推奨値は、同じオリジンにはURL全体を、別のオリジンには https://example.com/ のようなオリジンだけを伝え、HTTPSからHTTPへは何も送りません。指定が無いときの既定値でもありますが、OWASPは明示するよう勧めています。

URLに会員番号などを含むサイトでは、no-referrer や same-origin も選べます。ただし、Google Maps Platformの公式文書によると、この2つではRefererが送られず、Refererで制限したAPIキーが要求を拒否する場合があります。

X-Frame-Options と frame-ancestors の関係

X-Frame-Optionsは、自サイトのページを他サイトの枠（iframe）の中に表示させない指示で、クリックジャッキングを防ぎます。値は、すべての枠を拒否する DENY と、すべての親が同じオリジンのときだけ許す SAMEORIGIN の2つです。特定のサイトを許す ALLOW-FROM は廃止され、現在のブラウザはこの値を含むヘッダー全体を無視します。

特定のサイトにだけ埋め込みを許す方法は、CSPの frame-ancestors 'self' https://partner.example.jp のような指定です。CSPの仕様（W3C CSP Level 3）は、強制モードのCSPに frame-ancestors があれば、X-Frame-Optionsを無視すると定めています。Chrome 146でも、X-Frame-Options: DENY より frame-ancestors の許可が優先されます。

新旧のブラウザに対応するため、2つは併記できます。WordPressは管理画面やカスタマイザーで自サイトを枠の中に表示し、本体も SAMEORIGIN を付けるため、サーバー側もSAMEORIGINにそろえます。

Permissions-Policy

Permissions-Policyは、カメラ、マイク、位置情報などのブラウザ機能を、そのページと埋め込んだiframeで使えるかを決めます。値は機能ごとに、() で全面禁止、(self) で自サイトだけ、(self "https://map.example.jp") で指定のオリジンにも許可します。旧仕様のFeature-Policyの camera 'none' は、camera=() と書き換えます。

止めるのは、使っていない機能だけです。店舗検索で位置情報を使うなら geolocation=(self) にし、決済でPayment Request APIを使うなら payment は止めません。

付けないヘッダーと、消すヘッダー

X-XSS-Protectionは廃止されたヘッダーで、OWASPは付けないか、付けるなら 0 にするよう勧めています。古いブラウザのXSS検出機能が、安全なサイトにかえってXSSの弱点を生む場合があったためです。ChromiumがVersion 107で廃止したExpect-CTも、付ける必要はありません。

ServerとX-Powered-Byに出る版の表記は、Apacheならhttpd.confの ServerTokens Prod（.htaccessでは不可）で消します。nginxは server_tokens off;、PHPはphp.iniの expose_php = Off です。版を隠すだけでは安全にならないとApacheの公式文書も述べており、WordPressの本体とプラグインの更新のような更新作業を優先します。

Apache、nginx、WordPress、Cloudflareの設定例

段階1と2の4つのヘッダーに、HSTSの最初の値（max-age=300）を加えた設定例です。どの環境でも、404などのエラー応答とリダイレクトにもヘッダーが付く書き方を選ぶことが要点です。

Apache（.htaccess、VirtualHost）

# .htaccess、またはHTTPSのVirtualHostに書く
<IfModule mod_headers.c>
  # アプリが同名のヘッダーを出しても1本になるよう、unsetとalways setを対にする
  Header unset X-Content-Type-Options
  Header always set X-Content-Type-Options "nosniff"
  Header unset Referrer-Policy
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header unset X-Frame-Options
  Header always set X-Frame-Options "SAMEORIGIN"
  Header unset Permissions-Policy
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header unset Strict-Transport-Security
  Header always set Strict-Transport-Security "max-age=300"
  # PHPの版の表記を消す（PHPの動かし方で入る表が違うため2行とも書く）
  Header unset X-Powered-By
  Header always unset X-Powered-By
</IfModule>

Apacheの Header には、既定の「onsuccess」と「always」の2つの表があります。Apacheが自ら作る404やリダイレクト（RedirectやRewriteRuleの301）では、always の表しか使われず、always の無い指定は付きません（mod_headersの公式文書）。

PHPのヘッダーが入る表は動かし方で違い、mod_phpでは既定の表に、CGIやFastCGI（PHP-FPMなど）では always の表に入ります。Header always set だけではmod_phpでアプリの同名ヘッダーと2本並ぶため、例のように Header unset と対で書くと、どちらの方式でも1本になります。LiteSpeedなどApache互換のサーバーでは扱いが異なる場合があるため、設定後にcurlで本数を確かめます。

.htaccessの指定は、そのフォルダに届いた要求にだけ効き、VirtualHostやコントロールパネルで行うリダイレクトには付きません。HSTSは、変更できるならVirtualHostに書くのが確実です。mod_headersが無効な場合、<IfModule> で囲んだ指定は黙って無視され、囲まない指定は500エラーになります。

nginx

# /etc/nginx/snippets/security-headers.conf（共通の指定を1か所にまとめる）
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=300" always;

# HTTPSのserverブロック（証明書などの設定は省略）
server {
    listen 443 ssl;
    server_name example.com;
    server_tokens off;
    include snippets/security-headers.conf;

    location /assets/ {
        add_header Cache-Control "public, max-age=2592000";
        # add_headerを書いた場所では上の指定が消えるため、読み込み直す
        include snippets/security-headers.conf;
    }
}

nginxの add_header は、always が無いと200や301などの決まった応答にしか付かず、404や500には付きません（nginxの公式文書）。また、下の階層に add_header が1つでもあると、上の階層の add_header はすべて引き継がれません。例の /assets/ のように、キャッシュ用のヘッダーを足したlocationでセキュリティヘッダーが消えるのは、このためです。

対策は、共通のファイルを各locationで読み込み直すか、nginx 1.29.3以降（安定版は1.30.0以降）の add_header_inherit merge; をserverブロックに書く方法です。OSの標準パッケージは版が古いことがあるため、nginx -v で確かめてから選びます。アプリが出した同名のヘッダーは置き換わらずに残るので、PHP-FPMなら fastcgi_hide_header X-Frame-Options; のように隠します（リバースプロキシは proxy_hide_header）。

WordPress

サーバーの設定を変えられない場合は、WordPressの wp_headers フィルターで足せます。コードを wp-content/mu-plugins/ の直下に置くと自動で読み込まれ、テーマの変更でも消えず、管理画面から無効にもできません。

<?php
// wp-content/mu-plugins/security-headers.php として保存する
add_filter( 'wp_headers', function ( $headers ) {
    $headers['X-Content-Type-Options'] = 'nosniff';
    $headers['Referrer-Policy']        = 'strict-origin-when-cross-origin';
    $headers['X-Frame-Options']        = 'SAMEORIGIN';
    $headers['Permissions-Policy']     = 'camera=(), microphone=(), geolocation=()';
    return $headers;
} );

このフィルターは、公式リファレンスにあるとおりWP::send_headers()の中で適用され、効くのは公開ページの応答だけです。管理画面、ログイン画面、REST API、画像やCSSには付かないため、HSTSはサーバーかCDNで付けます。

WordPress 6.9以降は、管理画面とログイン画面に、本体が X-Frame-Options: SAMEORIGIN と frame-ancestors 'self' のCSPを付けます。サーバー側でCSPを付けるときは、この2つの画面でも値が食い違わないかの確認が必要です。

Cloudflare

Cloudflareでは、Rules Overviewの「Create rule」から「Response Header Transform Rule」を作ります。操作は、同名のヘッダーを上書きする「Set static」を選びます。「Add」は既存のヘッダーを残したまま足すため、オリジンの値と2本並びます。

HSTSは、Edge Certificatesの画面にある専用の設定で付けられます。マネージド変換の「Add security headers」は、OWASPが勧めない X-XSS-Protection: 1; mode=block や廃止済みのExpect-CTも付けるため、個別のルールで付ける方が推奨値にそろえやすくなります。

HSTSの設定方法と、max-ageを延ばす手順

HSTSは、HTTPSがサイト全体で安定してから、max-ageを5分、1週間、1か月と延ばし、最後に1年以上にします。HSTSを覚えたブラウザでは、証明書の期限切れなどのエラーのとき、利用者が警告を越えて進めなくなります。そのため、証明書の更新の自動化を先に済ませます。

HSTSを受け取ったブラウザは、受け取った時点からmax-ageの秒数だけそのホストを覚え、HTTPのURLもHTTPSに切り替えて接続します（RFC 6797）。HTTPの応答に付けたHSTSは無視されるため、HTTPSの応答に付けます。

1. 前提をそろえる全ページがHTTPSで表示され、混在コンテンツが無く、HTTPからHTTPSへ301で転送していることを確かめます。証明書の自動更新と期限の監視も整えます。期限の確かめ方は、SSL/TLS証明書のチェック方法で説明しています。
2. サブドメインを含めるか決めるincludeSubDomainsは、社内向けを含むすべてのサブドメインがHTTPSで動く場合だけ付けます。付けるなら、登録窓口のhstspreload.orgが勧める手順のとおり、最初の5分の段階から付けて試します。
3. max-age=300で配信する全ページと各サブドメインを開き、問い合わせ、決済、ログインまで動かします。
4. 1週間、1か月と延ばす604800、2592000の順に延ばします。各段階では、その値の期間が過ぎるまで待ってから次へ進みます。
5. 1年以上にする最終値は31536000（1年）以上にします。OWASPとhstspreload.orgの例は63072000（2年）です。

# 段階ごとの値（includeSubDomainsは、付けると決めた場合だけ）
Strict-Transport-Security: max-age=300; includeSubDomains
Strict-Transport-Security: max-age=604800; includeSubDomains
Strict-Transport-Security: max-age=2592000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains

CSPの設定例と、Report-Onlyからの段階導入

CSPは、まずContent-Security-Policy-Report-Onlyという名前で配信して違反を集め、正当な取得元を許可リストに足します。違反が出なくなったら、ヘッダー名をContent-Security-Policyに変えて強制します。Report-Onlyは読み込みを何も止めないので、本番のサイトで影響だけを測れるのが利点です。

1. Report-Onlyで配信する最初は、自サイト以外の取得元を違反として記録するだけの方針にします（下の設定例）。
2. 全ページを巡回して違反を集めるトップ、記事、フォーム、決済、管理画面まで開き、Consoleの違反を記録します。
3. 許可リストを直すアクセス解析、フォント、地図、動画などの取得元を、必要なディレクティブにだけ足します。
4. ヘッダー名を変えて強制する違反が出なくなったら、Content-Security-Policyに切り替えます。さらに厳しくする案は、Report-Onlyで同時に送って試せます。
5. nonceかハッシュで厳しくするインラインスクリプトを許す 'unsafe-inline' を外し、web.devが勧める厳格なCSPへ近づけます。

# Apache（行末の\は次の行へ続く印。\の後ろに空白を入れない）
Header always set Content-Security-Policy-Report-Only "default-src 'self'; \
    img-src 'self' data: https:; object-src 'none'; base-uri 'self'; \
    form-action 'self'; frame-ancestors 'self'"

# nginx（serverブロックに書く。長い値は変数に分けて組み立てる）
set $csp "default-src 'self'; img-src 'self' data: https:; ";
set $csp "${csp}object-src 'none'; base-uri 'self'; ";
set $csp "${csp}form-action 'self'; frame-ancestors 'self'";
add_header Content-Security-Policy-Report-Only $csp always;

default-srcが代わりを務めるのは、script-srcやimg-srcなどの取得系の指定だけです。base-uri、form-action、frame-ancestorsは個別に書きます。object-src 'none' はプラグインによる埋め込みを止める指定で、web.devの推奨にも含まれる値です。

Chrome 146では、違反はConsoleに情報（Info）として表示され、末尾に『The policy is report-only』で始まる一文が付きます。強制に切り替えると同じ違反がエラーになり、末尾は『The action has been blocked.』に変わります。インラインスクリプトの違反に示される『sha256-…』の値をscript-srcに足すと、そのスクリプトだけを許可できます。

違反をサーバーに集めるには、受け口を Reporting-Endpoints ヘッダーで示し、ポリシーに report-to を足します。設定例はMDNのContent-Security-Policy-Report-Onlyにあり、古いブラウザ向けに report-uri も併記しています。受け口には、ブラウザが送るJSONを保存する仕組みが別に要ります。

強制に切り替えた後は、web.devが勧める厳格なCSPへ近づけます。web.devは、ドメインを並べる許可リスト方式は多くの構成で回避されうるとし、nonce（応答ごとの乱数）かハッシュで許可する方式を勧めています。nonceは暗号学的に安全な乱数（128ビット以上が望ましい）で、応答のたびに作り直します。

# web.devが勧める厳格なCSP（{RANDOM}は応答ごとに作る乱数）
Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic';
    object-src 'none'; base-uri 'none';

# HTML側は、許可するscriptタグに同じ値を付ける
<script nonce="{RANDOM}" src="/js/app.js"></script>

同じヘッダーが2本届いたときに起きること

同名のヘッダーが2本届いたときの扱いはヘッダーごとに違い、HSTSは最初の1本だけ、CSPは両方が効いて厳しい側が勝ちます。X-Frame-Optionsは値が食い違うと、同じサイトの枠の中でも表示を拒否します。重複はエラーにならず黙って起きるため、確認の段階で本数を数えます。

根拠をChrome 146の動作とした行は、他のブラウザで扱いが異なる場合があります。重複を残さないことが、どのブラウザでも確実な対策です。

X-Frame-Optionsの値が食い違うと、Chrome 146はConsoleに次の例のように表示し、DENYとして扱います。

Refused to display 'https://example.com/' in a frame because it set multiple
'X-Frame-Options' headers with conflicting values ('DENY, SAMEORIGIN').
Falling back to 'deny'.

主な原因は、アプリとサーバーによる二重の付与と、Apacheの Header add やCloudflareの「Add」のような追加の操作です。付ける場所を1つに絞り、操作はsetにそろえます。

設定できたかをcurlと開発者ツールで確かめる

確認は設定ファイルではなく、外から取った実際の応答で行います。トップページ、存在しないURL、HTTPSのリダイレクト、画像やCSS、ログイン画面の5種類で、各ヘッダーが1本ずつ付いていれば合格です。

# ヘッダーだけを取得する（-IはHEADリクエスト）
curl -sI https://www.example.com/
# GETで取得し、応答ヘッダーだけを表示する
curl -s -D - -o /dev/null https://www.example.com/
# 404の応答にも付いているか
curl -sI https://www.example.com/no-such-page/
# wwwへ転送するリダイレクトに、HSTSが付いているか
curl -sI https://example.com/ | grep -i -E '^(HTTP|location|strict-transport)'
# 重複していないか（1なら合格）
curl -sI https://www.example.com/ | grep -ci '^x-frame-options:'
# Windows PowerShell 5.1は curl.exe と書き、findstrで絞る
curl.exe -sI https://www.example.com/ | findstr /i "x-frame-options"

Windows PowerShell 5.1では curl がInvoke-WebRequestの別名のため、.exe まで書きます。HEADとGETで違う応答を返すサーバーもあるので、GETの結果も見ておくと確実です。

• トップページ（200）に、入れたヘッダーがそれぞれ1本ずつ付いている
• 存在しないURL（404）にも、同じヘッダーが付いている
• wwwの有無をそろえる転送など、HTTPSのリダイレクトにHSTSが付いている
• 画像、CSS、JavaScriptにも付き、Content-Typeが種類どおりになっている
• ログイン画面や管理画面で、X-Frame-OptionsやCSPの値が食い違っていない

ブラウザでは、F12キーで開発者ツールを開き、Network（ネットワーク）タブで再読み込みします。先頭の文書を選んでHeaders（ヘッダー）のResponse Headers（レスポンス ヘッダー）を見て、CSPの違反はConsole（コンソール）タブで確かめます。

主なヘッダーをまとめて確かめるには、無料のWebサイトのセキュリティチェックも使えます。URLを入れると、HSTSの有無と有効期間、サブドメインへの適用、CSP、X-Frame-Optionsなど6種類のヘッダーを確認し、AからFの判定と直し方を表示します。ヘッダー以外の確認項目は、Webサイトのセキュリティチェック項目の一覧にまとめています。

表示や機能が壊れたときの戻し方

CSP、X-Frame-Options、Permissions-Policyは、設定を戻せば次の読み込みから元に戻ります。HSTSだけは、ブラウザが覚えた期間が残るため、すぐには戻せません。

ヘッダーの設定を1つのファイルにまとめて変更の履歴を残すと、1行の変更で戻せます。影響範囲を見極めにくい場合や、原因のヘッダーを切り分けられない場合は、診断や設定についての相談窓口からお問い合わせください。

よくある質問

関連記事

関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 関連記事SSL/TLS証明書のチェック方法｜有効期限・チェーン・通信方式の確認手順 関連記事WordPressの脆弱性を確認する方法｜本体・プラグインの更新と対処の手順 関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面

The post セキュリティヘッダーの設定方法｜HSTS・CSPの設定例つき 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 総合デジタルマーケティング企業 エスライン・テクノロジーズ.