セキュリティヘッダーとは？HSTS・CSPなどの役割と設定例｜Apache・nginx・WordPress

「診断ツールで『セキュリティヘッダーがありません』と出たが、何をすればよいのかわからない」「HSTSやCSPという言葉は聞くが、自社サイトに必要なのか判断できない」。Webサイトの安全性を見直すと、こうした疑問にぶつかることがよくあります。

この記事では、Webサイトを管理する企業の担当者向けに、セキュリティヘッダーの意味、主な6種類の役割、Apache・nginx・WordPress・CDNでの設定場所と設定例、設定で失敗しやすい注意点を整理します。内容はMDN Web DocsとOWASP Secure Headers Projectの説明に基づいています（2026年10月23日時点）。

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

セキュリティヘッダーとは、Webサーバーがページと一緒に返す「HTTPレスポンスヘッダー」のうち、ブラウザの動きを安全側に制限するための項目です。HTTPレスポンスヘッダーは、ページ本体とは別に送られる付加情報で、利用者の画面には表示されません。

たとえば「このページを他のサイトの枠（iframe）の中に表示させない」「必ずHTTPSで接続させる」といった指示をブラウザに伝えます。OWASP（Webアプリケーションのセキュリティに取り組む国際的な非営利団体）のSecure Headers Projectは、こうしたヘッダーの推奨値をまとめて公開しています。

関連記事WAFとは？ファイアウォール・IPSとの違い、種類と守れないもの｜中小企業のWebサイト・業務システムに必要か

関連記事中小企業の業務システムに必要なセキュリティ対策

主なセキュリティヘッダー6種類の役割

よく使われるのは次の6種類です。値の例は、MDNとOWASPの説明をもとにした一般的なものです。

X-Frame-OptionsとCSPのframe-ancestorsの関係

埋め込みの制限は、X-Frame-OptionsとCSPのframe-ancestorsのどちらでも指定できます。OWASPは、frame-ancestorsがX-Frame-Optionsに代わるものであり、両方ある場合はframe-ancestorsが優先されると説明しています。おおまかに「X-Frame-Options: DENY」は「frame-ancestors ‘none’」、「SAMEORIGIN」は「frame-ancestors ‘self’」に相当します。

特定の取引先サイトだけに埋め込みを許可したい場合は、frame-ancestorsで許可するサイトを並べます。X-Frame-Optionsの「ALLOW-FROM」は現在のブラウザでは無視されるため使いません。古いブラウザへの配慮として、両方を同じ内容で出しておく方法もあります。

現在は不要とされるヘッダー

X-XSS-Protectionは、OWASPでは非推奨とされています。かえって問題を起こすことがあるため、出す場合も「0」にし、XSS対策はCSPで行います。また、OWASPは、Server（Webサーバーのソフトとバージョン）やX-Powered-By（PHPのバージョンなど）のように、内部の情報を明かすヘッダーは削除するよう勧めています。攻撃者に古いバージョンを知られる手がかりになるためです。

関連記事PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618・109619）｜業務システムで確認すること・修正版・8.1以前の対応【2026年10月】

設定する場所と設定例

セキュリティヘッダーは、Webサーバー、アプリケーション（WordPressなど）、CDNのいずれかで付けられます。複数の場所で付けると、同じヘッダーが2つ出たり、どこで変えればよいかわからなくなったりします。管理しやすい場所を1か所に決めるのが基本です。

Apache（.htaccess）の例

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Strict-Transport-Security "max-age=31536000" "expr=%{HTTPS} == 'on'"
</IfModule>

IfModuleで囲むと、mod_headersがない環境でもエラーになりません。HSTSはHTTPS接続のときだけ付くようにしています。記述を誤るとサイト全体が表示できなくなることがあるため、編集前に元のファイルを保存しておきましょう。

nginxの例

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000" always;

HTTPSのserverブロックに書きます。「always」を付けると、エラーページなどにも付きます。注意したいのは、nginxでは下の階層（locationなど）に1つでもadd_headerがあると、上の階層のadd_headerは引き継がれないことです。特定のlocationにだけ別のヘッダーを足したら、セキュリティヘッダーがすべて消えていた、という失敗がよくあります。設定後は実際のレスポンスで確認しましょう。

WordPress（send_headersフック）の例

add_action( 'send_headers', function () {
    header( 'X-Content-Type-Options: nosniff' );
    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
} );

send_headersは、WordPressがページのヘッダーを送るときに呼ばれる仕組み（フック）です。子テーマのfunctions.phpや自作の小さなプラグインに書きます。親テーマに直接書くと、テーマの更新で消えてしまいます。

CDNで設定する場合

CDN（コンテンツ配信ネットワーク）を使っている場合は、管理画面でレスポンスヘッダーを追加できることが多く、画像などを含むすべての応答にそろえて付けやすいのが利点です。サーバー側と重複しないよう、どちらで管理するかを決めます。

設定するときの注意点

強く設定するほど安全になる一方で、サイトの表示や機能を壊すおそれもあります。特に次の点に注意してください。

• HSTSは短い期間から始める：HSTSを受け取ったブラウザは、max-ageの期間中はHTTPで接続しなくなります。設定を間違えても、すぐには取り消せません。まず短い期間で問題がないことを確認してから、1年（31536000秒）などに延ばすと安全です
• includeSubDomainsはすべてのサブドメインを確認してから：すべてのサブドメインにHTTPSを強制します。HTTPSに対応していない社内向けのサブドメインや古いシステムがあると、ブラウザから開けなくなります
• preloadは原則として使わない：preloadは、ブラウザに最初から組み込まれる一覧（プリロードリスト）に登録するための指定です。OWASPは、一覧からの削除に時間がかかるため、標準ではpreloadを付けないよう勧めています。登録するなら、includeSubDomainsの影響を確認したうえで判断します
• CSPは「レポートのみモード」から：CSPをいきなり本番で有効にすると、外部のスクリプトやインラインのスクリプトが止まり、アクセス解析、フォーム、地図、チャットなどが動かなくなることがあります。MDNは、まずContent-Security-Policy-Report-Onlyで違反だけを記録し、問題がなくなってから本番に切り替える方法を勧めています
• X-Frame-Optionsで正当な埋め込みが壊れないか確認する：自社のページを取引先のサイトやグループ会社のポータルにiframeで載せている場合、DENYやSAMEORIGINで表示されなくなります。必要な埋め込みがあるなら、CSPのframe-ancestorsで許可するサイトを指定します
• 設定後は実際のヘッダーを確認する：ブラウザの開発者ツール（ネットワーク）で、トップページ、下層ページ、エラーページに想定どおり付いているかを確かめます

CSPのレポートのみモードは、次のように指定します。報告の受け取り先（report-uriなど）は、別途用意が必要です。

Content-Security-Policy-Report-Only: default-src 'self'; frame-ancestors 'self'

関連記事システム障害の対応フローと再発防止策

関連記事Webサイトのセキュリティチェックリスト20項目｜担当者が自分で確認できる方法と頻度（IPAの20ヶ条と整合）

導入の進め方

担当者が少ない企業でも進めやすい順番は、次のとおりです。

1. 現状を確認する今どのヘッダーが返っているか、ServerやX-Powered-Byでバージョンが表示されていないかを確認する
2. 設定場所を決めるサーバー、WordPress、CDNのどこで管理するかを決め、誰が変更できるかを整理する
3. 影響の少ないものから入れるX-Content-Type-Options、Referrer-Policy、X-Frame-Optionsを入れ、埋め込みや表示に問題がないか確認する
4. HSTSを短い期間で入れる全ページがHTTPSで表示でき、HTTPからHTTPSへ転送されることを確かめてから、期間を少しずつ延ばす
5. CSPをレポートのみモードで試す違反の記録を見ながら許可する取得元を決め、問題がなくなってから本番に切り替える

開発会社や保守会社にサイトを任せている場合は、どのヘッダーをどこで設定しているかを、保守の資料に残してもらいましょう。担当者が替わっても設定の意図がわかり、サーバー移行のときに設定が抜け落ちるのを防げます。

関連記事脆弱性診断の費用相場と実施タイミング

関連記事企業サイトのWordPressセキュリティ対策｜被害の原因と対策の優先順位、PHP更新・バックアップ・月次の保守チェック表

よくある質問

まとめ

セキュリティヘッダーは、ブラウザに安全な扱い方を指示することで、クリックジャッキングやXSS、通信のすり替えなどの被害を減らす設定です。X-Content-Type-Options、X-Frame-Options、Referrer-Policyのように入れやすいものから始め、HSTSは短い期間から、CSPはレポートのみモードから段階的に進めましょう。設定場所を1か所に決め、設定後は実際のヘッダーを確認することが大切です。ヘッダーだけでは脆弱性は直らないため、ソフトウェアの更新やWAFなど、ほかの対策と組み合わせて考えてください。

参考：MDN Web Docs「Strict-Transport-Security」「X-Content-Type-Options」「X-Frame-Options」「CSP: frame-ancestors」「Content Security Policy (CSP) implementation」「Referrer-Policy」「Permissions-Policy」「Apache Configuration: .htaccess」、OWASP Secure Headers Project「Response Headers」「Best Practices」、nginx「Module ngx_http_headers_module」、WordPress Developer Resources「send_headers」（いずれも2026年10月23日確認）。

関連記事システム保守契約に含めるべき内容とSLA