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

セキュリティヘッダーは影響の小さい順に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 総合デジタルマーケティング企業 エスライン・テクノロジーズ.