セキュリティ対策

セキュリティヘッダは「並べる」ものではない — 今も効くもの、もう要らないもの、入れると害になるもの

ネット上のセキュリティヘッダ一覧は更新が止まっているものが多く、いまだに廃止済みのヘッダを勧めています。X-XSS-ProtectionはMDNで非推奨かつ非標準とされ、しかも『本来安全なサイトにXSSの脆弱性を作り出しうる』と警告されています。今も設定すべきヘッダと、外すべきヘッダを一次情報で切り分けます。

公開日 2026-09-05 更新日 2026-09-05 最終確認 2026-09-05 12分で読める

セキュリティヘッダの設定例は、ネット上にいくらでも見つかります。問題は、その多くが更新されていないことです。数年前に正しかった一覧をそのままコピーすると、もう役目を終えたヘッダと、入れると害になり得るヘッダまで一緒に持ち込むことになります。

① 今も設定すべき6つ

当サイトのセキュリティヘッダ診断ツールが基準にしているのは、次の6つです。廃止されたヘッダは意図的に含めていません。

推奨する6つと、それぞれが担当していること

Content-Security-Policy: 読み込んでよいスクリプト・リソースの出どころを宣言する。XSSが起きたときの被害の幅を狭める中核。frame-ancestors で埋め込みも制御できる
Strict-Transport-Security: 以後このサイトへは必ずHTTPSで来いとブラウザに記憶させる。最初の平文アクセスを潰す（max-age と includeSubDomains）
X-Frame-Options: 他サイトからのフレーム埋め込みを拒否する。クリックジャッキング対策。CSPの frame-ancestors と併用するのが実務上の定番
X-Content-Type-Options: nosniff。ブラウザに中身を見て型を推測させない。アップロードされたファイルが意図しない型として解釈される事故を減らす
Referrer-Policy: 遷移先へ渡す参照元情報を絞る。URLに載った情報の漏えいを防ぐ（そもそもURLに秘密を載せないのが前提）
Permissions-Policy: カメラ・マイク・位置情報などのブラウザ機能を既定で無効化する。使わない機能は閉じておく

入れる順番：壊れにくいものから

実務では導入の順番が効きます。X-Content-Type-Options・X-Frame-Options・Referrer-Policy・Permissions-Policy は既存の表示を壊しにくく、効果が確実なので先に入れられます。Strict-Transport-Security はHTTPSが全経路で確実に動いてから（記憶されるため、後戻りが効きにくい）。

CSPは最後で、段階的に。影響範囲が最も大きく、いきなり厳しくすると正規の機能が止まります。組み立ては CSPビルダーで試しながら進めてください。

② もう役目を終えたもの

Expect-CT：2021年6月時点でほぼ不要

MDNはこのヘッダを非推奨（Deprecated）とし、こう説明しています——実装していたのは Google Chrome と Chromium 系ブラウザのみで、Chromium はバージョン107からこのヘッダを非推奨にした。理由は Chromium が証明書の透明性（CT）を既定で強制するようになったから。さらに「Expect-CT は2021年6月時点でほぼ時代遅れ」と注記されています。

つまりブラウザ側が既定でやるようになったので、サイト側から指示する必要が消えたという経緯です。新規に足す理由はありません。

③ 入れると害になり得るもの

X-XSS-Protection：非推奨・非標準であるうえに、XSSを作り出しうる

MDNはこのヘッダに「非推奨（Deprecated）」と「非標準（Non-standard）」の両方を掲げたうえで、警告としてこう書いています——「この機能はCSPに対応しない古いブラウザの利用者を保護できる場合があるが、場合によっては X-XSS-Protection が、本来安全なサイトに XSS の脆弱性を作り出しうる」。

そして推奨は明確です——「XSSフィルタリングの代わりに Content-Security-Policy を使うことが推奨される」。

ここが「ヘッダは多いほど良い」が崩れる決定的な例です。善意で足した設定が、状況によっては攻撃面になる。 設定していないなら足さない、すでに入っているなら外す判断をしてください。XSSそのものへの対処は XSSとはを参照。

よくある「古い一覧」の姿

CSP・HSTS・X-Frame-Options・nosniff に加えて、
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …

数は多く、点数を稼ぐ診断サイトもあるかもしれません。しかし現在のブラウザに対しては、効かないか、害になり得ます。

今の実務

CSP を軸に据え、残り5つで支える。

廃止されたヘッダは足さない・外す。ヘッダの数ではなく、CSPの質（'unsafe-inline' をどれだけ排除できているか）に労力を向けるほうが、実際の防御力に効きます。

大前提：ヘッダは穴を塞がない

アプリ側の欠陥（XSS・認可漏れ・アップロード）

ヘッダを何枚足しても消えない

↓ 発生した場合

ヘッダが効く範囲

外部への持ち出し先を絞る／埋め込みを止める／平文接続を止める＝被害の広がりを制限する

ヘッダが変えるのは「穴があるかどうか」ではなく「穴があったとき、どこまで広がるか」。

XSSのあるサイトにCSPを入れても、XSSは消えません。悪用の幅が狭まるだけです。だから順序は——まずアプリ側の欠陥を直し、ヘッダは多層防御の1枚として重ねる。逆に言えば、ヘッダの診断が満点でも、それは安全の証明にはなりません。

自分のサイトで確認する

いま何が返っているかを実測する

設定ファイルを読むのではなく、実際のレスポンスを見ます。リバースプロキシ、CDN、フレームワーク、アプリ——複数の層がヘッダを足したり上書きしたりするため、設定と実際の出力は一致しないことがあります。当サイトのセキュリティヘッダ診断はURLを入れるだけで実測できます。

廃止済みのヘッダが混じっていないか確認する

X-XSS-Protection と Expect-CT が返っていたら、外す方向で検討してください。とくに前者は、上に書いたとおり害になり得ると警告されています。

壊れにくい4つを先に入れる

X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Referrer-Policy: strict-origin-when-cross-origin、Permissions-Policy（使わない機能を閉じる）。表示を壊しにくく、効果が確実な4つです。

HSTSはHTTPSが完全に動いてから

Strict-Transport-Security はブラウザに記憶されるため、HTTPSに問題がある状態で入れると復旧が面倒になります。全経路がHTTPSで動くことを確認してから。証明書運用の基礎は Let's Encrypt とはにまとめています。

CSPは段階的に、そして本丸へ

最初は緩めから始め、'unsafe-inline' を外せるかを目標に詰めていきます。ここがCSPの効き目を決める分岐点です。組み立ては CSPビルダーで。あわせてセキュリティ最低限チェックリストの他項目も確認してください。

当サイトの視点：設定のコピペは「鮮度」が寿命を決める

セキュリティヘッダは、コピペで済ませたくなる代表格です。だからこそ、コピー元がいつのものかで安全性が変わります。本記事で扱った2つは、どちらも「かつては正しかった」設定です。X-XSS-Protection に至っては、当時の推奨がそのまま現在の警告対象になっています。

当サイトの立場は、ヘッダ設定を「一度やる作業」ではなく「たまに見直す設定」として扱うこと。そして診断ツールの点数を目的にしないこと——点数は、廃止済みヘッダを足しても上がってしまうことがあります。数を増やすのではなく、CSPの質を上げるほうに時間を使ってください。

出典（一次情報）

MDN Web Docs「X-XSS-Protection」 — developer.mozilla.org（Deprecated／Non-standard の表示、「本来安全なサイトにXSSの脆弱性を作り出しうる」という警告、CSPを使うべきという推奨）
MDN Web Docs「Expect-CT」 — developer.mozilla.org（Deprecated の表示、Chromium 107での非推奨化とその理由、2021年6月時点でほぼ不要という注記）

いずれも2026-09-05に確認。

次に読む

よくある質問

QX-XSS-Protection は設定すべきですか？

いいえ。MDNはこのヘッダを『非推奨（Deprecated）』かつ『非標準（Non-standard）』としたうえで、警告として『古いブラウザの利用者を保護できる場合がある一方、本来安全なサイトに X-XSS-Protection が XSS の脆弱性を作り出しうる』と明記しています。そして『XSSフィルタリングの代わりに Content-Security-Policy を使うことが推奨される』としています。設定していないなら足さない、設定しているなら外す判断をしてください。

QExpect-CT はもう不要ですか？

はい。MDNは『Expect-CT は2021年6月時点でほぼ時代遅れ』とし、実装していたのは Google Chrome と Chromium 系ブラウザのみで、Chromium はバージョン107からこのヘッダを非推奨にした——理由は Chromium が証明書の透明性（CT）を既定で強制するようになったから、と説明しています。新規に足す理由はありません。

Q結局どれを設定すればいいですか？

当サイトのヘッダ診断ツールが基準にしている6つが実用的な出発点です。Content-Security-Policy、Strict-Transport-Security、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy。廃止されたヘッダは意図的に含めていません。順番としては、壊れにくく効きが確実なもの（nosniff・X-Frame-Options・HSTS）を先に入れ、CSPは影響範囲が大きいので段階的に導入するのが現実的です。

Qヘッダを全部入れれば安全になりますか？

なりません。ヘッダは『アプリの穴を塞ぐもの』ではなく『被害の広がり方を制限するもの』です。XSSがあるサイトにCSPを入れても、XSSが消えるわけではありません——悪用の幅が狭まるだけです。順序としては、まずアプリ側の欠陥を直し、ヘッダは多層防御の1枚として重ねてください。逆に言えば、ヘッダの点数が満点でも安全の証明にはなりません。