WordPress管理画面の「ツール ＞ サイトヘルス」を開いた際、「おすすめの改善」の中に「Not all essential security headers are installed（Your website does not send all essential security headers.）」という英語の項目が表示され、その下に6つの専門用語が並んでいて戸惑った方も多いのではないでしょうか。
この表示は、Webサーバーから訪問者のブラウザへ送られる6種類の「HTTPセキュリティヘッダー（安全な通信・表示を行うための指示書）」がまだ設定されていないことを知らせる案内です。サーバーの .htaccess ファイルに数行の設定コードを追記することで、これら6項目を一括で有効化できます。
本記事では、サイトヘルスに並ぶ6つのセキュリティヘッダー（Upgrade Insecure Requests・X-XSS protection・X-Content Type Options・Referrer-Policy・Permissions-Policy・HTTP Strict Transport Security）それぞれの意味と必要性を身近な例えで分かりやすく解説し、.htaccess を使って設定・解消する手順を紹介します。
あわせて読みたい（サイトヘルスの改善とSSL・セキュリティの基礎）
同じくサイトヘルスに表示されるHTTPSリダイレクト設定については「「301 .htaccess 転送」とは？WordPressサイトヘルスの改善表示の意味と仕組み・必要性を分かりやすく解説」、SSL通信の仕組みについては「SSLとは？独自SSLと共有SSLの違い・仕組み・サーバー管理画面の見方を図解で解説」もあわせてご覧ください。
なぜサイトヘルスに「Not all essential security headers are installed」と出るのか？
まず、画面に表示されている英語メッセージの意味を確認しておきましょう。
- Not all essential security headers are installed（推奨される必須セキュリティヘッダーの一部が設定されていません）
- Your website does not send all essential security headers.（あなたのWebサイトは、主要なセキュリティヘッダーをすべて送信していません）
読者がChromeやSafariなどのブラウザでWebサイトを開くと、Webサーバーはページの文章や画像データ（HTML）と一緒に、目に見えない通信の添え状である「HTTPレスポンスヘッダー」をブラウザへ渡しています。その中でも、ブラウザに対して「このページを表示する時は、安全のために以下のルールを守ってください」と指示する項目を「セキュリティヘッダー（HTTP Security Headers）」と呼びます。
宅配便に例えるなら、Webページ本体が「箱の中の荷物」だとすると、セキュリティヘッダーは箱の外側に貼る「ワレモノ注意」「天地無用」「本人確認必須」といった取扱指示ラベルです。ラベルが貼られていなくても荷物は届きますが、貼っておくことで配達員（ブラウザ）がルールに従って慎重に扱ってくれるため、道中での盗み見やすり替え、誤作動といったトラブルを未然に防ぐことができます。
サイトヘルスに並ぶ6つのセキュリティヘッダー早見表
一つひとつの詳しい解説に入る前に、サイトヘルスで指摘される6つの項目が「何を防ぎ、どんな指示を出しているのか」を一覧表で俯瞰してみましょう。
| ヘッダー項目名 | 一言でいうと（ブラウザへの指示） | 防げるリスク・効果 |
|---|---|---|
| Upgrade Insecure Requests | ページ内の古い http:// 画像やリンクを自動で https:// に読み替える |
「保護されていない通信（混在コンテンツ）」警告の防止 |
| X-XSS protection | ブラウザ内蔵の旧式XSS（不正スクリプト）検知フィルターを制御する | 悪意あるスクリプト混入への対策・旧ブラウザの誤作動防止 |
| X-Content Type Options | ファイル形式をブラウザが勝手に推測（スニッフィング）して実行するのを禁止する | 画像に見せかけた不正プログラムの自動実行を阻止 |
| Referrer-Policy | 外部リンクをクリックした際、移動先へ伝える「参照元URL（リファラー）」の範囲を制限する | URL内のパラメータや非公開パスの外部漏洩を防止 |
| Permissions-Policy | カメラ・マイク・位置情報（GPS）などの端末機能をサイト上で勝手に使わせない | 外部広告や埋め込みパーツによるスマホ機能の無断使用を防止 |
| HTTP Strict Transport Security | 今後このサイトには最初から必ず https:// だけで接続するようブラウザに記憶させる |
初回接続時の通信盗聴・改ざん（中間者攻撃）を防止 |
前半3つのセキュリティヘッダーの仕組みと役割
ここからは、6つのセキュリティヘッダーについて前半3つと後半3つに分けて、それぞれの仕組みと設定値を詳しく見ていきます。
Upgrade Insecure Requests（混在コンテンツを自動でHTTPS化する指示）
「Upgrade Insecure Requests（安全でないリクエストのアップグレード）」は、Content-Security-Policy（CSP） ヘッダーの指定項目のひとつです。
長年運営しているブログを途中からSSL化（HTTPS化）した場合、過去の記事本文やウィジェットの中に http:// から始まる古い画像URLや外部リンクが一部残ってしまうことがあります。このように「ページ自体は https:// なのに、ページ内部で http:// のパーツを読み込んでいる状態」を混在コンテンツ（Mixed Content）と呼び、ブラウザのアドレスバーで鍵マークが外れたり画像が表示されなくなったりする原因になります。
このヘッダー（Content-Security-Policy: upgrade-insecure-requests）を送っておくと、ブラウザがページ内のリソースを読み込む際、自動的に http:// を安全な https:// に書き換えてリクエストしてくれるため、混在コンテンツによる警告や表示崩れをスマートに防げます。
X-XSS protection（クロスサイトスクリプティング検知フィルターの制御）
「X-XSS protection（X-XSS-Protection）」は、Webページに悪意のあるプログラム（JavaScript）を紛れ込ませる「クロスサイトスクリプティング（XSS）攻撃」に対するブラウザ内蔵フィルターの動作を指定するヘッダーです（XSSなどの攻撃手法の基礎については「フィッシング詐欺やマルウェアとは？知っておきたいセキュリティ用語まとめ【図解】」でも解説しています）。
かつてのブラウザ（Internet Explorerや旧Edge、旧Safariなど）には簡易的なXSS検知フィルターが搭載されており、X-XSS-Protection: 1; mode=block（検知したらページ表示をブロックする）という指定が広く使われていました。一方、近年の最新ブラウザではこの旧式フィルター自体が廃止され、誤検知による副作用を避けるために 0 または 1; mode=block のいずれかを明示的に出力しておく運用が採られています。サイトヘルスの診断チェックでも、このヘッダーが明示的に出力されていれば改善項目がクリアされます。
X-Content Type Options（ファイル形式の勝手な推測実行を防ぐ指示）
「X-Content Type Options（X-Content-Type-Options: nosniff）」は、ブラウザのお節介な機能である「MIMEスニッフィング（中身推測）」を禁止するための非常に重要なヘッダーです。
Webブラウザには、サーバーから「これは画像ファイル（image/jpeg）やテキストファイル（text/plain）です」と渡されたデータであっても、中身を覗き見て「中にプログラムコードが書かれているから、プログラムとして実行してあげよう」と勝手に判断してしまう性質（スニッフィング）があります。もし悪意ある第三者が、コメント欄やアップロード機能を通じて「画像に見せかけた不正プログラム」を送り込んだ場合、この推測機能が働くと訪問者のブラウザ上でウイルスや不正スクリプトが実行されてしまいます。
ここに nosniff（嗅ぎ回らない＝推測しない）を指定することで、「サーバーが申告したファイル形式通りにだけ扱い、中身を勝手にプログラムとして実行しない」ようブラウザに厳命できます。
後半3つのセキュリティヘッダーの仕組みと役割
続いて、リストの後半に並んでいる3つのセキュリティヘッダー（Referrer-Policy・Permissions-Policy・HTTP Strict Transport Security）の役割を見ていきましょう。
Referrer-Policy（外部サイトへ移動する際の参照元URL情報を制限するルール）
読者があなたのブログ内のリンクをクリックして別のWebサイトへ移動したとき、ブラウザは移動先のサイトに対して「どのページのリンクからやって来たか」という情報（リファラー：Referer）を自動的に伝えます。
もし何も制限していない場合、URLの末尾に含まれる細かなパラメータや、限定公開ページ・管理画面のURLパスまでそのまま外部サイトへ伝わってしまうことがあります。かといってリファラーを「一切送らない（no-referrer）」設定にしてしまうと、今度はアフィリエイトリンクの成果計測やアクセス解析が正常に機能しなくなるデメリットがあります。
そこで現代のWeb標準として推奨されているのが、strict-origin-when-cross-origin という設定値です。これを指定すると以下のように賢く振る舞います。
- 自分のサイト内でページ移動する時：記事のパスまで含めた全体のURLを伝える（サイト内解析が正確に動く）。
- 外部の安全なHTTPSサイトへ移動する時：詳細なページパスは伏せて、ドメイン名（
https://example.com/）だけを伝える（アフィリエイト計測とプライバシー保護を両立できる）。 - 暗号化されていないHTTPサイトへ移動する時：安全のためリファラー情報を一切伝えない。
Permissions-Policy（カメラ・マイク・位置情報などの端末機能をロックするルール）
「Permissions-Policy（パーミッションポリシー / 旧 Feature-Policy）」は、スマートフォンやパソコンのブラウザが備えている強力なハードウェア機能（カメラ、マイク、GPS位置情報、USB接続、ジャイロセンサー、決済APIなど）の使用権限を、サイト側であらかじめ制限するヘッダーです。
通常のブログ記事を読むだけであれば、カメラやマイクを起動する必要はありません。あらかじめ camera=(), microphone=(), geolocation=() のように空のカッコ () を指定して「使用不可」にロックしておくことで、万が一外部の広告スクリプトや埋め込みパーツ（iframe）に不審なコードが紛れ込んだ場合でも、訪問者のカメラや位置情報が勝手に使われるのをブロックできます。
HTTP Strict Transport Security（HSTS：初回接続からHTTPS通信を強制する宣言）
6つの中でも特に重要なのが、「HTTP Strict Transport Security（通称：HSTS / ヘッダー名：Strict-Transport-Security）」です。
前の記事（301 .htaccess 転送の解説）で紹介したとおり、301リダイレクトを設定しておけば http:// でアクセスされてもサーバーが https:// へ転送してくれます。しかし厳密に言うと、訪問者が http:// のリンクをクリックしてサーバーから「HTTPSへ移動してください」と返事が返ってくるまでの「最初の1往復」だけは暗号化されていないHTTP通信が発生してしまいます。悪意ある攻撃者がカフェの無料Wi-Fi等で待ち伏せし、この最初の1往復に割り込んで偽サイトへ誘導する手口を「SSLストリッピング攻撃（中間者攻撃）」と呼びます。
HSTSヘッダー（例：max-age=31536000＝1年間有効）を設定すると、一度でもあなたのサイトを訪れたブラウザは「このドメインは今後1年間、たとえ http:// のリンクがクリックされてもサーバーに問い合わせる前にブラウザ内部で強制的に https:// へ書き換えて接続する」と記憶します。これにより、最初の1往復目から安全な暗号化通信が守られます。
.htaccessに追記して6つのセキュリティヘッダーを設定する手順
ここからは、エックスサーバーやConoHa WING、ロリポップ！、さくらインターネットなどの一般的なレンタルサーバー（Apache / LiteSpeed環境）において、.htaccess ファイルに追記してサイトヘルスの6つの改善項目を一括クリアする手順を解説します。
コピペで使える .htaccess 追記コード（6項目すべて対応）
レンタルサーバーの管理画面にある「.htaccess編集」機能（またはファイルマネージャー／FTPソフト）を開き、編集前の内容をメモ帳などにコピーしてバックアップを取ったうえで、.htaccess ファイルの末尾（# END WordPress の下の行など）に以下のコードを追記して保存します。
# BEGIN Security Headers（サイトヘルス推奨の6項目を一括設定）
<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()"
Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>
# END Security Headersコード内の安心設計ポイント
<IfModule mod_headers.c> 〜 </IfModule>で囲んでいるため、万が一サーバー側でヘッダー変更モジュール（mod_headers）が無効な環境であってもエラーを起こさず安全にスキップされます。- 最後の行の
Strict-Transport-Security（HSTS）は、他サイトでよく紹介されているincludeSubDomains; preloadをあえて外し、シンプルな"max-age=31536000" env=HTTPSにしています。もし将来、SSL化していないテスト用サブドメインを作った際にブラウザからアクセス不能になる事故を防ぐためです（サブドメインもすべて常時SSL化している場合は"max-age=31536000; includeSubDomains"にしても問題ありません）。 Permissions-Policyでは、一般的なブログで不要な8つのセンサー・端末機能（加速度センサー、カメラ、位置情報、ジャイロ、磁気センサー、マイク、決済、USB）を明示的にオフ（()）に設定しています。
設定後にサイトヘルスから警告が消えたか確認する方法
.htaccess を保存したら、以下の流れで反映を確認しましょう。
- トップページと記事ページの表示確認：まずご自身のサイトをブラウザで開き、画面が正常に表示されるか、画像や埋め込みパーツ（YouTubeやSNS埋め込み等）に問題がないか確かめます。
- キャッシュのクリア：サーバー側のキャッシュ機能などを利用している場合は、一度キャッシュを削除します。
- 「ツール ＞ サイトヘルス」を再読み込み：WordPress管理画面のサイトヘルスを開き直すと、「Not all essential security headers are installed」の項目が「おすすめの改善」から消え、「問題ない項目」の中へ移動していることが確認できます。
まとめ
WordPressのサイトヘルスに表示される「Your website does not send all essential security headers.」の意味と、6つのセキュリティヘッダーそれぞれの役割、そして .htaccess での設定手順について解説しました。最後に要点を振り返ります。
本記事のポイントまとめ
- セキュリティヘッダーとは：Webサーバーから訪問者のブラウザへ渡す「安全な通信・表示ルールの指示書」であり、ブラウザ側での自動防御を有効にする仕組み。
- 前半3つの役割：
Upgrade Insecure Requestsでページ内の古いHTTPパーツを自動HTTPS化し、X-XSS-ProtectionとX-Content-Type-Options: nosniffで不正スクリプトや偽装ファイルの勝手な実行を防ぐ。 - 後半3つの役割：
Referrer-Policyで外部サイトへ渡す参照元URLを適切に絞り、Permissions-Policyでカメラやマイクの無断起動をロックし、HSTSで初回アクセス時からHTTPS通信を強制する。 - .htaccessへの追記で一括設定が可能：事前に
.htaccessのバックアップを取ったうえで、mod_headersの6行を追記することで6項目すべてを有効化できる。
サイトヘルスの「おすすめの改善」は、致命的なエラーではないものの、設定しておくことで読者のブラウザとサイト双方の安全性を一段階引き上げてくれる有益な項目です。ぜひ本記事のコードを参考に、.htaccess のバックアップを取ったうえで設定してみてください。
