ドメイン番人
Web セキュリティWordPressWeb 担当者How-to

WordPress でセキュリティヘッダを設定する｜Web 担当者向け実践手順

ドメイン番人約 6 分で読めます
目次

この記事でわかること

  • WordPress でセキュリティヘッダを設定する 3 つの方法と選び方
  • Web 担当者向けの推奨設定（.htaccess に追加するブロック）
  • WordPress 特有の落とし穴（プラグイン依存・テーマ更新リスク）
  • 設定後の確認手順

WordPress でセキュリティヘッダを設定する 3 つの方法

WordPress でセキュリティヘッダを設定する 3 つの方法

1. .htaccess（推奨）

Apache 環境（多くのレンタルサーバー）で最も標準的。プラグイン削除や WordPress / テーマの更新に左右されません。

メリット

  • プラグイン依存なし、軽量
  • WordPress 本体・テーマと独立して維持される
  • Cloudflare 等の CDN 配下でも併用できる

デメリット

  • Nginx 環境では別の設定が必要（Nginx 設定ファイル直接編集）
  • 文法ミスで全画面 500 になるリスクあり（バックアップ必須）

2. プラグイン（HTTP Headers / Really Simple SSL 等）

管理画面 GUI で設定できる。

メリット

  • 非技術者でも設定可能
  • Apache / Nginx 両環境で動く

デメリット

  • プラグインを削除すると設定も消える
  • プラグインのメンテ停止リスク
  • 動作の重さ

3. テーマの functions.php に PHP コードを追加

add_action('send_headers', function () {
  header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
  header('X-Frame-Options: SAMEORIGIN');
  header('X-Content-Type-Options: nosniff');
  header('Referrer-Policy: strict-origin-when-cross-origin');
});

メリット

  • プラグイン不要
  • Apache / Nginx 両対応

デメリット

  • テーマ変更で消える
  • 子テーマ前提
  • テーマ更新時の差分管理が必要

Web 担当者向け推奨設定（.htaccess 編）

.htaccess の先頭付近（WordPress の生成ブロックの前）に以下を追加します。

WordPress 推奨ヘッダ設定

<IfModule mod_headers.c>
  # HSTS - 初回は max-age=86400（1 日）で動作確認、問題なければ 31536000（1 年）に拡大
  # 詳細な段階導入は [HSTS の設定方法](/blog/hsts-settei-houhou) を参照
  Header always set Strict-Transport-Security "max-age=86400"
  # 動作確認後に上の行をコメントアウトして以下を有効化:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

  # クリックジャッキング対策
  Header always set X-Frame-Options "SAMEORIGIN"

  # MIME スニッフィング対策
  Header always set X-Content-Type-Options "nosniff"

  # Referer 漏洩制御
  Header always set Referrer-Policy "strict-origin-when-cross-origin"

  # ブラウザ機能の許可リスト（使わない機能を全部止める）
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"

  # CSP は最初 Report-Only で（即時 enforce すると WP テーマが崩壊する可能性大）
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; report-uri /wp-json/csp-report/v1/log"
</IfModule>

注意点

  • mod_headers モジュールが有効である必要がある（多くのレンタルサーバーで標準有効）
  • .htaccess 編集前に必ずバックアップを取る（編集ミスで全画面 500 になり管理画面に入れなくなる事故が多い）
  • 反映後はブラウザで複数ページ表示確認 + 開発者ツールで Response Headers を確認

WordPress 特有の落とし穴

プラグインがインラインスクリプトを大量に出す

'unsafe-inline' を CSP の script-src に入れないと、Contact Form 7 / WooCommerce / Yoast SEO 等の主要プラグインが動作不能になることがあります。本記事の推奨設定でも 'unsafe-inline' を含めていますが、これは「現実的な妥協」であり、本来は CSP の unsafe-inline 撤去 を段階的に進めるべきです。

管理画面（/wp-admin/）の例外

WordPress 管理画面は古いコードベースのためインライン JS / インラインスタイルを多用しています。CSP を厳しくすると管理画面が崩壊するケースがあるので、管理画面と公開ページで CSP を分ける実装を検討してください。

<If "%{REQUEST_URI} =~ m#^/wp-admin/#">
  # 管理画面用は緩める
  Header always set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval'"
</If>
<Else>
  # 公開ページは厳しく
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'"
</Else>

テーマ更新時の差分管理

functions.php 方式を選んだ場合、テーマ更新で上書きされないよう 子テーマを必ず使う運用にしてください。

設定後の確認

ブラウザの開発者ツール

F12 → Network タブ → 任意のページを再読み込み → リクエストを選択 → Response Headers にヘッダが出ていることを確認。

コマンドライン

curl -I https://example.co.jp/

レスポンスヘッダの中に追加したセキュリティヘッダが含まれていれば成功です。

ドメイン番人の単発チェック

Web セキュリティヘッダ 単発チェック で 30 秒で全ヘッダの状態がスコアリングされます。設定漏れや誤った値の検出に便利です。

まとめ

  • 推奨は .htaccess 設定（プラグイン非依存・軽量）
  • Nginx 環境ではプラグイン or サーバー直接編集
  • CSP は最初 Report-Only で観察して段階的に Enforce へ
  • 管理画面と公開ページで CSP を分ける設計が現実的

まずは現状を把握しましょう

ドメイン番人の Web セキュリティヘッダ 単発チェック で 30 秒で確認できます。設定支援が必要な場合は Web セキュリティヘッダ診断＋設定支援（3 万円〜）でご相談ください。

各ヘッダの個別解説:

サーバー別の設定: Cloudflare で セキュリティヘッダを設定する / Nginx で セキュリティヘッダを設定する も参照してください。

総合点検は 無料のドメイン診断 を、SSL 単独は SSL 単発チェック をご利用ください。

関連記事

次の一歩は無料診断から。

無料診断を試す →相談したい方はこちらから