サイトの診断ツールやセキュリティの点検で「セキュリティヘッダーが設定されていません」と指摘されることがあります。
WordPressの初期状態では、公開ページにセキュリティヘッダーはほとんど付きません。
この記事では、6種類のヘッダーの役割と、WordPressで設定する2つの書き方、設定できたかを確かめる手順を紹介します。
この記事で使うセキュリティヘッダー診断は、当サイトと同じMOTOKI合同会社が作った「WEBツール箱」の1つです。
無料で、会員登録なしで使えます。
最終確認日：2026年9月28日
この記事で分かること
- セキュリティヘッダー6種類の役割
- 今のサイトの設定を確かめる手順
- .htaccessとfunctions.phpでの書き方
- CSPだけは慎重に進める理由
セキュリティヘッダーとは
セキュリティヘッダーは、サーバーがページと一緒にブラウザーへ送る「このページはこう扱ってください」という指示です。
設定していないとすぐに侵入されるものではなく、万一の攻撃で被害を小さくするための備えです。
ツールでは、次の6種類を100点満点で採点します。
| ヘッダー | 防ぐもの | 配点 |
|---|---|---|
| Strict-Transport-Security（HSTS） | HTTPでの接続による盗み見や改ざん | 20 |
| Content-Security-Policy（CSP） | 改ざんされたスクリプトの実行 | 20 |
| X-Content-Type-Options | 画像などに偽装したスクリプトの実行 | 15 |
| X-Frame-Options | 他サイトに埋め込んでクリックをだまし取る攻撃 | 15 |
| Referrer-Policy | 移動先のサイトへのURLの漏れ | 15 |
| Permissions-Policy | 使わないカメラ・マイク・位置情報の呼び出し | 15 |
X-Frame-Optionsは、CSPの「frame-ancestors」で代わりに設定していても満点になります。
HSTSは、有効期間（max-age）が半年より短いと点数が半分になります。
今のサイトの設定を確かめる
- セキュリティヘッダー診断を開く
- 調べたいサイトのURLを入れて「診断する」を押す
- 点数と、6種類それぞれの結果が出る
- 足りないものがあれば、そのまま貼れる.htaccessの設定例が出る
ツールはページに1回アクセスして、返ってきたヘッダーを読むだけです。
攻撃を試すようなことはしません。
実際に調べた結果
wordpress.org｜25点
wordpress.orgの診断の結果です。
設定されていたのはHSTSとX-Frame-Optionsの2つだけで、25点でした。
HSTSは有効期間が3600秒（1時間）と短いため、半分の10点になっています。
結果の下には、足りない4種類をまとめた.htaccessの設定例が出ます。
WordPressの配布元でも、公開ページのヘッダーはこの程度しか付いていません。
このサイト｜80点
このサイトでは、CSPを除く5種類を設定しています。
足りないのはCSPだけなので、設定例にもCSPの1行だけが出ました。
WordPressのサイトでは、CSPだけが最後に残ることがよくあります。
理由は後の「CSPは様子見から始める」で説明します。
WEBツール箱｜94点
WEBツール箱は6種類すべてを設定していて、94点でした。
満点にならないのは、CSPに「unsafe-inline」が入っているためです。
ページの中に直接書いたスクリプトを許可する指定で、これがあるとCSPの効き目が下がります。
WordPressで設定する方法
設定する場所は、サーバーの設定ファイル（.htaccess）か、テーマのfunctions.phpのどちらかです。
| 方法 | 向いているサイト | 効く範囲 |
|---|---|---|
| .htaccess | ApacheやLiteSpeedで動くレンタルサーバー | その.htaccessが適用されるパスの応答。CDNや別サーバーのファイルは別確認 |
| functions.php | .htaccessを使えないサーバー、テーマ側で管理したい場合 | WordPressが作る公開ページだけ |
.htaccessに書く
ツールが出した設定例を「コピー」で写し、サイトのルートにある.htaccessに貼ります。
貼る場所は「# BEGIN WordPress」から「# END WordPress」までの外にしてください。
この2行の間は、パーマリンクの設定を保存したときにWordPressが書き換えるため、中に書いた設定が消えることがあります。
IfModuleはモジュールが無い場合に中の設定を省略しますが、構文ミスや許可されない設定による500エラーまでは防ぎません。編集前に.htaccessを保存し、エラー時は追加部分を戻します。
ツールが出す設定例の1行は、次のような形です。
Header always set \
X-Content-Type-Options "nosniff"ここでは画面の幅に合わせて2行に分けています。
行末の「\」は次の行へ続くという意味の記号で、Apacheはこのままでも1行として読みます。
迷ったら、ツールの出力のとおり1行で貼ってください。
functions.phpに書く
子テーマのfunctions.phpか、Code Snippetsのようなコードを追加するプラグインに書きます。
WordPressには、ページを送る直前に動く「send_headers」という仕組みがあり、そこでヘッダーを足します。
add_action( 'send_headers', function () {
$h = array(
'X-Content-Type-Options'
=> 'nosniff',
'X-Frame-Options'
=> 'SAMEORIGIN',
'Referrer-Policy'
=> 'strict-origin-when-cross-origin',
'Permissions-Policy'
=> 'camera=(), microphone=(), '
. 'geolocation=()',
);
foreach ( $h as $k => $v ) {
header( "$k: $v" );
}
} );この方法で付くのは、WordPressが作る公開ページだけです。
画像やCSSなどのファイル、管理画面には付きません。
なお、WordPress本体はログイン画面と管理画面にだけ「X-Frame-Options: SAMEORIGIN」を自動で付けています。
Referrer-Policyの値の選び方は「Referrer-Policyをレスポンスヘッダーに追加する方法」で一覧にしています。
HSTSは常時SSL化が済んでから
HSTSは、ブラウザーに「このドメインは決めた期間、HTTPSでしか開かない」と覚えさせる指示です。
設定したあとにHTTPSをやめると、覚えたブラウザーからはサイトが開けなくなります。
すべてのページがHTTPSで開けることを確かめてから設定してください。
不安なときは、有効期間を300秒のように短くして試し、問題が無ければ1年（31536000秒）に伸ばします。
ツールの設定例にある「includeSubDomains」は、サブドメインにも同じ指示をかける指定です。
HTTPSに対応していないサブドメインがある場合は、この指定を外してください。
CSPは様子見から始める
CSPは、ページが読み込んでよいスクリプトや画像の出どころを限る指示です。
CSPは読み込み元やスクリプトの実行を制限しますが、設定を誤ると表示や機能が止まります。ヘッダー間で効果を一律に順位付けはできません。
WordPressでは、テーマやプラグインがページの中にスクリプトを直接書き込むことが多く、解析タグ・広告・埋め込み動画も外のドメインから読み込みます。
そのため、いきなり本番に適用せず、次の手順で進めます。
- ヘッダー名を「Content-Security-Policy-Report-Only」にして設定する（止めずに、違反だけをブラウザーに記録する）
- サイトの主なページと、問い合わせフォームを開く
- ブラウザーの開発者ツールの「Console」に出た違反を見て、必要な出どころを許可に足す
- 主要な操作とログイン状態を変えて確認し、許可先を必要最小限に見直したうえで本適用する。コンソールの警告だけを消すために許可を広げない
ツールが出すCSPの設定例は、多くのサイトで動くよう「unsafe-inline」を含めた緩めの内容です。
満点を目指すより、サイトが止まらないことを優先してください。
ツールを使わずに確かめる方法
ヘッダーは、ブラウザーの開発者ツールでも見られます。
- 調べたいページを開き、F12キー（Macはcommand＋option＋I）で開発者ツールを開く
- 「Network」タブを選び、ページを再読み込みする
- 一番上に出るページ本体の行をクリックし、「Headers」の「Response Headers」を見る
コマンドで確かめる場合は、curlを使います。
curl -sS -D - -o /dev/null https://wordpress.org/2026年9月28日のHEAD要求では、「Strict-Transport-Security: max-age=3600」と「X-Frame-Options: SAMEORIGIN」が返りました。
現在の確認では上のGETコマンドを使い、通常のページ取得と同じ方法でヘッダーを比較します。
Windowsではcurl.exeを使い、/dev/nullをNULに置き換えます。
ツールの結果と同じです。
キャッシュ系のプラグインやCDNを使っている場合は、古いヘッダーが残って見えることがあります。
設定を変えたら、キャッシュを消してから確かめてください。
よくある質問
Q. 満点ならサイトは安全ですか？
安全とは言えません。
ヘッダーはセキュリティ対策の一部で、プラグインの脆弱性やパスワードの管理は別に対策が要ります。
Q. 設定したらサイトが表示されなくなりました
多くはCSPが原因です。
CSPの行を消すか、「Report-Only」に戻して表示を確かめてください。
.htaccessを編集して画面が真っ白になった場合は、貼った行を消して元に戻します。
Q. Nginxのサーバーでも.htaccessは使えますか？
Nginxだけで動くサーバーでは.htaccessは読まれません。
その場合は、サーバーの設定で指定するか、functions.phpの方法を使います。
まとめ
- 今の設定はセキュリティヘッダー診断にURLを入れれば分かる
- .htaccessの適用範囲と実際の応答を確認する
- functions.phpに書くと、WordPressの公開ページにだけ付く
- HSTSは常時SSL化が済んでから、短い期間で試す
- CSPはReport-Onlyで様子を見てから本適用する
SSL証明書の有効期限もあわせて確かめるなら、SSL証明書チェックが使えます。
ほかの項目もまとめて点検するなら、「WordPressサイトを自分で点検する手順」で順番と使い分けを解説しています。
ツールの一覧はWEBツール箱にあります。
functions.phpの例はWordPressがPHPで生成する対象応答の設定です。CDNやページキャッシュが直接返す応答には処理が走らない場合があります。変更前後に実際のレスポンスヘッダーを比較し、埋め込み・フォーム・カメラなど必要な機能を確認します。すでにサーバー側に設定がある場合は重複や競合を避け、管理場所を決めてください。
ApacheとWordPressで確認した適用範囲
| 確認対象 | 隔離環境での結果 |
|---|---|
| PHP例を読み込んだ記事ページ | 200。nosniff・SAMEORIGIN・Referrer-Policy・Permissions-Policyを確認 |
| 画像などに相当する静的ファイル | 200。PHP例の4種類は追加されなかった |
| REST API・ログイン画面 | PHP例の4種類は一括追加されなかった。本体のヘッダーは別に存在する |
| Apache例を置いた範囲の静的ファイル | nosniffあり。追加設定を戻すと付かなくなった |
2026年10月3日、隔離したApache 2.4.69・PHP CGI 8.2.29・WordPress 7.1.2で、掲載のPHP例とApacheの複数行の設定例を実行しました。
WordPressがPHPで作る記事ページでは、PHP例の4種類のヘッダーを確認できました。
REST APIにはWordPress本体が別途nosniffを付けるため、それをPHP例の成果と取り違えないようにします。
ログイン画面も本体のヘッダーと追加コードのヘッダーを分けて確認してください。
この試験のCGIはScriptAliasでPHP実行ファイルへ処理を渡す構成です。
ルートの.htaccessに書いたヘッダーは静的ファイルに付きましたが、ログイン画面には届きませんでした。
Apacheであっても設置場所だけで全応答への適用を保証せず、設定を読み込む範囲と実際の応答を確認します。
これは今回のCGI構成の結果であり、他のホストのPHP実行方式へ一律に当てはめるものではありません。
ヘッダーの取得を確認した結果です。
ブラウザーでのCSP違反、フォーム・埋め込みの動作、HSTSの保存状態やPC・スマホの表示は別途確認が必要です。
