セキュリティヘッダーとは？Webサイトで設定する意味

セキュリティヘッダーとは、Webサーバーがブラウザへ返すHTTPレスポンスヘッダーを使って、「このページではどのような動作を許可するか」「HTTPSだけを使うか」「他サイトのiframeに埋め込ませるか」などの安全ルールを伝える仕組みです。

代表例にはContent-Security-Policy（CSP）、Strict-Transport-Security（HSTS）、X-Content-Type-Options、Referrer-Policy、X-Frame-Options、Permissions-Policyなどがあります。

ただし、ヘッダーを多く付ければ安全になるわけではありません。設定を厳しくしすぎると、JavaScript、外部フォント、埋め込み動画、決済画面などが動かなくなることがあります。

30秒でわかる結論

セキュリティヘッダーは、ブラウザへ安全な動作ルールを伝えるHTTPレスポンスヘッダー
CSPは読み込み元・実行元を制限し、XSSなどの被害軽減に使う
HSTSは、対応ブラウザへHTTPSだけで接続するよう指示する
X-Frame-Optionsは、他サイトによるiframe埋め込みを制限しクリックジャッキング対策に使う
WordPress初心者は、サーバー・CDNの標準機能を確認し、CSPやHSTSを自己判断で一括設定しない
X-Content-Type-OptionsはMIME sniffingを抑止し、Referrer-PolicyはReferer情報の送信範囲を制御する
Permissions-Policyはブラウザ機能を制御し、X-XSS-ProtectionやHPKPなど古いヘッダーは現在の推奨状況を確認する

セキュリティヘッダーとは？

WebサーバーはHTMLや画像だけでなく、レスポンスの付加情報としてHTTPヘッダーをブラウザへ送ります。

その中には、ブラウザのセキュリティ動作を指定できるヘッダーがあります。これらをまとめて「セキュリティヘッダー」と呼びます。

Webサーバー → HTTPレスポンスヘッダー → ブラウザが安全ルールを適用

役割の例

HTTPではなくHTTPSだけを使わせる
許可したドメイン以外からスクリプトを読み込ませない
他サイトのiframeへ埋め込ませない
不要なブラウザ機能を使わせない
リンク先へ送る参照元情報を制限する

OWASP Secure Headers Projectでは、HTTPレスポンスヘッダーを使ってブラウザの挙動を制限し、予防可能な脆弱性や攻撃のリスクを下げる考え方が整理されています。

セキュリティヘッダーだけでWebサイトは安全になる？

なりません。

セキュリティヘッダーは重要な防御層ですが、WordPress本体・テーマ・プラグインの脆弱性、弱いパスワード、不正ログイン、サーバー設定ミスなどを自動的に直すものではありません。

位置づけ

アップデート・認証・WAF・バックアップなどの基本対策に、ブラウザ側の防御としてセキュリティヘッダーを追加すると考えてください。

代表的なセキュリティヘッダー一覧

ヘッダー	主な役割
Content-Security-Policy	読み込み・実行可能なコンテンツ元を制限
Strict-Transport-Security	HTTPS接続を強制
X-Content-Type-Options	MIME sniffingを抑止
Referrer-Policy	Referer情報の送信範囲を制御
X-Frame-Options	iframe等への埋め込みを制限
Permissions-Policy	ブラウザ機能の利用を制御

全部を同じ重要度で設定しない

サイト構成によって必要なポリシーは異なります。特にCSP・HSTS・Permissions-Policyは、実際の外部サービスやサブドメイン構成を確認してから設定します。

Content-Security-Policy（CSP）とは？

CSPは、ブラウザがどこからJavaScript・CSS・画像・フォントなどを読み込めるかを制限するセキュリティヘッダーです。

考え方

自サイトと許可したCDNからだけスクリプトを読み込む
↓
想定外のスクリプト実行を制限する

XSSの被害軽減などに有効ですが、WordPressサイトではアクセス解析、広告、YouTube埋め込み、Google Fonts、決済サービスなど外部リソースを使うことが多いため、厳しいCSPを突然適用すると機能が止まる可能性があります。

コピーしたCSPをそのまま使わない

他サイトのCSPは、そのサイトの構成に合わせたものです。自分のサイトで利用している外部ドメインを調査してから設計してください。

CSPの詳しい設定項目は、別記事「CSPとは？Content Security Policyの仕組みを解説」で扱います。

Strict-Transport-Security（HSTS）とは？

HSTSは、ブラウザへ「このサイトは今後HTTPSだけで接続する」と伝えるヘッダーです。

MDNでは、Strict-Transport-SecurityがHTTPではなくHTTPSを使うようブラウザへ指示する仕組みとして説明されています。

イメージ

最初にHTTPSへ正常接続
↓
ブラウザがHSTSルールを記憶
↓
次回からHTTP接続をHTTPSへ切り替える

HTTPSが完全に使える状態で設定する

HSTSを長期間有効にすると、証明書やHTTPS設定に問題が起きた際もブラウザがHTTPへ戻らなくなります。HTTPS化・サブドメイン構成を確認してから設定してください。

HSTSのincludeSubDomainsは慎重に使う

HSTSには、ルールをサブドメインにも適用する設定があります。

対象例

www.example.com
mail.example.com
shop.example.com
old.example.com

サブドメインの中にHTTPS非対応のサービスが1つでも残っている場合、まとめて適用するとアクセスできなくなる可能性があります。

初心者の判断

HSTSのサブドメイン適用やpreloadは、意味を理解せず有効化しないでください。まず通常のHTTPS運用が安定していることを確認します。

X-Content-Type-Optionsとは？

X-Content-Type-Optionsは、ブラウザがレスポンスの内容を推測して別の種類として扱う「MIME sniffing」を抑えるために使われます。

代表的な設定

X-Content-Type-Options: nosniff

MDNでは、nosniffによってブラウザがContent-Typeで示された種類を尊重し、MIME sniffingを行わないようにすると説明されています。

比較的導入しやすい

正しいContent-Typeを返している一般的なサイトでは、CSPより導入影響を確認しやすいヘッダーです。ただし、古い構成や誤ったContent-Typeがあるサイトでは表示・読込問題が表面化することがあります。

Referrer-Policyとは？

Webページから別ページへ移動するとき、ブラウザはRefererヘッダーで参照元情報を送ることがあります。

Referrer-Policyは、その参照元情報をどこまで送るか制御するヘッダーです。

制御できること

参照元を送らない
同一オリジンだけ送る
外部サイトにはオリジンだけ送る
HTTPSからHTTPへは送らない

OWASPではstrict-origin-when-cross-originなど複数のポリシーが整理されています。

アクセス解析への影響も確認

参照元情報を厳しく制限すると、外部サイト側や一部の解析で取得できる情報が減る場合があります。プライバシーと分析要件を見て決めます。

X-Frame-Optionsとは？

X-Frame-Optionsは、自分のページを他サイトのiframeなどへ埋め込めるかを制限するヘッダーです。

主にクリックジャッキング対策に使われます。

クリックジャッキングのイメージ

攻撃者サイトに対象ページを見えにくく重ねる
↓
利用者に別のボタンだと思わせてクリックさせる

値の違いやCSPのframe-ancestorsとの関係は、別記事「X-Frame-Optionsとは？クリックジャッキング対策を解説」で扱います。

Permissions-Policyとは？

Permissions-Policyは、Webページや埋め込んだiframeがブラウザ機能を利用できる範囲を制御する仕組みです。

対象になる機能の例

カメラ
マイク
位置情報
全画面表示
その他のブラウザ機能

MDNでは、Permissions-PolicyをWebサイト自身や埋め込んだiframeについて、ブラウザ機能の使用を許可・拒否する仕組みとして説明しています。

OWASP Secure Headers Projectでは、Permissions-Policyは現在「Working draft」として整理されています。利用する機能とブラウザ対応を確認し、必要なディレクティブだけを設定してください。

機能を使うサイトでは要確認

Web会議、カメラ撮影、位置情報、外部iframeなどを利用するサイトでは、厳しく設定しすぎると必要機能が動かなくなる場合があります。

古いセキュリティヘッダーにも注意する

以前は推奨されたものでも、現在は非推奨・廃止扱いになっているヘッダーがあります。

ヘッダー	現在の考え方
X-XSS-Protection	古いブラウザ向け機能。現在は非推奨
Public-Key-Pins	HPKP。廃止・使用非推奨
Expect-CT	現在は廃止方向
Feature-Policy	Permissions-Policyへ移行

OWASP Secure Headers Projectの現行一覧でも、X-XSS-Protection、Public-Key-Pins、Expect-CT、Feature-Policyなどは非推奨・廃止側に整理されています。

古い記事をそのまま使わない

数年前の「おすすめセキュリティヘッダー一覧」をコピーすると、現在は不要な設定が混ざる可能性があります。必ず現行仕様を確認してください。

セキュリティヘッダーとHTTPSの違い

対策	主な役割
HTTPS	通信を暗号化・認証する
セキュリティヘッダー	ブラウザの動作や許可範囲を制御する

HTTPSを使っているからCSPやクリックジャッキング対策が不要になるわけではありません。逆に、セキュリティヘッダーを設定しても、HTTP通信そのものが暗号化されるわけではありません。

HTTPS＝通信を守る
セキュリティヘッダー＝ブラウザの動作を制御する

セキュリティヘッダーとWAFの違い

WAFは、Webアプリケーションへ送られる不正な通信を検知・遮断する防御です。

一方、セキュリティヘッダーはレスポンスとしてブラウザへ送られ、ブラウザ側の動作を制御します。

対策	主な場所
WAF	サーバー・CDN側で通信を検査
セキュリティヘッダー	ブラウザ側でポリシーを適用

どちらか一方ではない

WAF、更新、認証、HTTPS、セキュリティヘッダーを組み合わせる多層防御として考えます。

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

WordPressサイトでは、複数の場所でセキュリティヘッダーを追加できます。

代表的な設定場所

レンタルサーバーの管理画面
Apacheの設定・.htaccess
Nginx設定
CDN・リバースプロキシ
WordPressプラグイン
アプリケーション側

複数箇所で重複設定しない

サーバー、CDN、プラグインの複数箇所から同じヘッダーを出すと、値が重複・競合して意図しない挙動になる場合があります。どこで管理するかを1つずつ確認してください。

共用レンタルサーバーではどうする？

共用レンタルサーバーでは、利用者がWebサーバーの全設定を変更できない場合があります。

1．公式マニュアルを確認

2．管理画面に設定機能があるか確認

3．.htaccess等が利用可能か確認

4．CDN側ですでに付与されていないか確認

5．テストしてから本番適用

初心者は標準機能を優先

レンタルサーバーやCDNがセキュリティヘッダー設定機能を提供しているなら、まず公式手順を利用する方が管理しやすいです。

VPSではWebサーバー側で設定する

VPSでは、Apache・NginxなどのWebサーバー設定でHTTPレスポンスヘッダーを追加することができます。

自由度が高い一方、設定ミスの影響も自分で管理します。

適用前の確認

設定ファイルのバックアップ
構文チェック
テスト環境での表示確認
外部JavaScript・CSSの動作確認
iframe・決済・動画埋め込みの確認
HTTPS・サブドメインの確認

セキュリティヘッダーの確認方法

ブラウザの開発者ツールを使えば、実際のHTTPレスポンスヘッダーを確認できます。

1．ブラウザの開発者ツールを開く

2．Networkを開く

3．対象ページを再読み込み

4．HTMLドキュメントを選ぶ

5．Response Headersを確認

確認する名前

content-security-policy
strict-transport-security
x-content-type-options
referrer-policy
x-frame-options
permissions-policy

オンライン診断だけで設定を決めない

セキュリティヘッダーを採点するオンラインツールもありますが、点数だけを目的に設定を追加するのはおすすめしません。

サイトで必要な外部サービスや機能を理解せず、厳しいCSPやPermissions-Policyを入れると、正常な機能まで止まる可能性があります。

満点より正常動作と適切なポリシー

診断結果は「何が未設定かを知る材料」として使い、実際に必要なヘッダーと値はサイト構成に合わせて決めます。

設定後に確認するページ

最低限の動作確認

トップページ
WordPress管理画面
ログイン画面
お問い合わせフォーム
決済ページ
動画・地図・SNS埋め込み
アクセス解析
広告

セキュリティヘッダーは全ページへ共通適用されることがあるため、トップページだけ表示できたからといって完了とは限りません。

CSPはReport-Onlyから試せる

CSPには、違反するリソースをすぐブロックせず、違反状況を報告するためのReport-Onlyモードがあります。

導入イメージ

現在の外部リソースを調査
↓
Report-Onlyで違反候補を確認
↓
必要な読み込み元を整理
↓
本番ポリシーへ移行

OWASP Secure Headers Projectでも、Content-Security-Policy-Report-Onlyがレポート専用のレスポンスヘッダーとして整理されています。

複雑なサイトほど段階導入

広告・解析・外部API・埋め込みが多いサイトほど、いきなり強制モードを設定せず、影響を確認しながら導入します。

セキュリティヘッダーでよくある失敗

よくあるミス

ネット上の設定例をそのままコピーする
HSTSをHTTPS確認前に有効化する
includeSubDomainsを意味なく付ける
CSPでGoogle Analyticsや決済を止める
サーバーとCDNで同じヘッダーを二重設定する
古いX-XSS-ProtectionやHPKPを追加する
設定後にスマホ・フォームをテストしない

どのヘッダーから確認すればよい？

一般的な会社サイト・WordPressサイトでは、まずHTTPSが正常に動作していることを前提に、比較的基本的なヘッダーから確認します。

優先	ヘッダー	判断
基本	X-Content-Type-Options	nosniffを検討
基本	Referrer-Policy	送信範囲を決める
要確認	HSTS	HTTPS・サブドメインを確認後
要設計	CSP	外部リソースを調査して設計
用途次第	X-Frame-Options	埋め込み要件を確認
用途次第	Permissions-Policy	必要ブラウザ機能を確認

万能の「おすすめセット」はない

ブログ、EC、会員サイト、Webアプリでは必要な機能が異なります。ヘッダー名だけでなく値までサイトごとに設計してください。

初心者はセキュリティヘッダーを自分で設定すべき？

共用レンタルサーバーで一般的なWordPressサイトを運営しているなら、最初から複雑なCSPを手書きする必要はありません。

個人ブログ

優先：基本対策

更新、HTTPS、強いパスワード、バックアップを優先し、サーバー標準ヘッダーを確認します。

会社サイト

優先：確認推奨

基本ヘッダーとHSTS・フレーム制御を確認し、外部サービスに合わせて調整します。

EC・会員サイト

優先：高

CSPを含む多層防御を、決済・ログイン機能と合わせて設計します。

独自Webアプリ

優先：高

CSP、Permissions-Policy、クロスオリジン系ポリシーまでアプリ要件に合わせて設計します。

セキュリティヘッダーを設定する順番

STEP1．HTTPSを正常化する

STEP2．現在のレスポンスヘッダーを確認する

STEP3．外部サービス・iframe・ブラウザ機能を洗い出す

STEP4．必要なヘッダーだけ設計する

STEP5．テスト環境で設定する

STEP6．フォーム・決済・埋め込み等を確認する

STEP7．本番適用後もブラウザ・ログを監視する

教科書判定

セキュリティヘッダーは「全部入れる」のではなく、サイト構成を確認して段階的に設定する

初心者が最優先するのは、WordPress・テーマ・プラグインの更新、HTTPS、認証、バックアップなどの基本対策です。

そのうえで、X-Content-Type-OptionsやReferrer-Policyなどの基本ヘッダーを確認し、HSTSはHTTPS構成、CSPは外部リソース、X-Frame-Optionsはiframe要件を確認して設定してください。

特にCSP・HSTSは、意味を理解せずネット上の設定例をコピーするとサイト機能へ影響する可能性があります。共用レンタルサーバーでは、サーバー会社やCDNの公式機能・マニュアルを優先するのが安全です。

また、X-XSS-ProtectionやHPKPなど古い情報をそのまま採用せず、現在も有効な仕様か確認してから設定してください。

FAQ

Q．セキュリティヘッダーとは簡単にいうと何ですか？

Webサーバーからブラウザへ送るHTTPレスポンスヘッダーを使って、HTTPS利用、スクリプト読み込み、iframe埋め込みなどの安全ルールを指定する仕組みです。

Q．WordPressにセキュリティヘッダーは必要ですか？

有効な防御策の1つです。ただし、設定前にサーバーやCDNがすでに付与していないか確認し、WordPress更新・認証・バックアップなどの基本対策と組み合わせてください。

Q．CSPを設定すればXSSは完全に防げますか？

完全には防げません。CSPは強力な追加防御ですが、入力検証・サニタイズ・出力エスケープなど、アプリケーション側の根本対策も必要です。

Q．HSTSは必ず設定した方がよいですか？

HTTPSが完全に安定しているサイトでは有効ですが、サブドメインや証明書の状態を確認せず長期間設定するとトラブルになる場合があります。構成を確認してから導入してください。

Q．X-XSS-Protectionは設定した方がよいですか？

現在は古いブラウザ向けの仕組みで、OWASP Secure Headers Projectでは非推奨・廃止側に整理されています。XSS対策は安全な実装とCSPなど現在の対策を優先してください。

まとめ

この記事の結論

セキュリティヘッダーはブラウザの安全動作を制御するHTTPレスポンスヘッダー
CSPはコンテンツの読み込み・実行元を制限する
HSTSはHTTPS接続を強制する
X-Content-Type-OptionsはMIME sniffingを抑止する
Referrer-Policyは参照元情報の送信範囲を制御する
X-Frame-Optionsはクリックジャッキング対策に使う
Permissions-Policyはブラウザ機能の利用を制御する
古いX-XSS-ProtectionやHPKPを無条件に追加しない
設定前後にフォーム・決済・埋め込みなどの動作を確認する
WordPress初心者はサーバー・CDNの公式機能を優先する

セキュリティヘッダーはWebサイトを守る有効な防御層ですが、数を増やすこと自体が目的ではありません。現在のサイト構成と必要機能を確認し、影響をテストしながら必要なものだけ設定してください。

次に読む

「CSPとは？Content Security Policyの仕組みを解説」「X-Frame-Optionsとは？クリックジャッキング対策を解説」「XSSとは？クロスサイトスクリプティングの仕組みと対策」もあわせて確認してください。