ほとんどのサイトがまだスキップしているセキュリティヘッダー：49 実際の監査からのデータ
レスポンスヘッダーはデプロイ時に付随する単一行の設定です。監査対象のサイトでは大多数がそれらを送信していません — Permissions-Policy は 69% に欠如し、リストで最も採用されているヘッダーは 41% にも欠如しています。
このレポートでは、監査したすべてのサイトについて、リダイレクト後の最終的なホームページのレスポンスから 6 つのセキュリティヘッダーを読み取りました。 リダイレクト前のホップでのみ送信されるヘッダーはカウントされません。ブラウザがそれをページに適用することはないためです。 質問は意図的に狭いです：レスポンスにヘッダーが存在したかどうか。
49 サイトを 23 から August 31, 2026 の間で監査した結果、答えは通常「いいえ」. Permissions-Policy はそれらの 69% に欠如し、Referrer-Policy は 65%、Content-Security-Policy は 61%、X-Frame-Options は 51%、X-Content-Type-Options は 43%、Strict-Transport-Security — 6 の中で最も採用されているもの — は 41% に欠如しています。
方法論：現在のチェックセットから各ドメインの最新完了監査スナップショット、約 23 から August 31, 2026、49 個別ドメイン、匿名化済み。 各パーセンテージは、ホームページのレスポンスがそのヘッダーを持っていなかったサイトの割合です。 サンプルは自己選択で、監査を実行したオーナーのみで構成され、主に小規模・中規模サイトに偏っています。これは、ウェブ全体でのヘッダー採用率を過小評価する可能性があります。大規模プラットフォームはエッジでこれらを設定しています。 シェアは長尾に対して方向性を示すものとして扱ってください。
これらの数値は存在を数えるもので、品質ではありません
測定の精度は重要です。これにより、これらの数値が主張できる上限が決まります。
これらの数値は、サイトごとに 1 つのレスポンス、つまりリダイレクト後のホームページを表しています。 存在とは空でない値を意味し、それ以上のものではありません。 max-age が 1 秒の Strict-Transport-Security ヘッダーも存在としてカウントされ、何でも許容する Content-Security-Policy も同様です。 存在は、ポリシーが適切に構築されているかどうかについて何も示しません。
これは弱い指標に見えますが、測定内容を考慮するとそうではありません。 何らかの値を持つヘッダーは、人間がサーバー設定、CDN ルール、またはミドルウェアファイルを開き、指令を入力した証拠です。 この測定は、サイトの設定層が意図的に触れられたかどうかをテストします — それが失敗率が興味深い部分であり、合格率ではありません。
すでに配信しているヘッダーが実際に何かを守っているかどうかは、2 つの点で決まります：
- Report-only CSP は何も強制しません。
Content-Security-Policy-Report-Onlyは違反をブロックせずにログに記録します。 始め方としては正しいものの、強制するContent-Security-Policyヘッダーを配信するまで、ポリシーは何も守りません。 frame-ancestorsと X-Frame-Options は異なるクライアントに届きます。 CSP のframe-ancestorsディレクティブはより良い制御ですが、古いクライアントはレガシーのX-Frame-Optionsヘッダーしか読みません。 両方を配信してください。
受容はヘッダーの古さを追跡し、難易度を追跡しません
失敗率の順序は逆クロノロジカルに近いです。6 つのうち最も古い HSTS は、すべての主要な CDN ダッシュボードでトグルに還元でき、最も採用されています。 X-Content-Type-Options と X-Frame-Options は、正式な後継者よりもはるかに前から存在するベンダー慣例であり、中央に位置しています。 Referrer-Policy と Permissions-Policy は最新の二つで、最も欠落している — さらに Permissions-Policy は共通ホストがあなたの代わりに設定しないため、最後に位置します。
いずれも工学的に他より難しいわけではありません。 6 つのうち 5 つはサーバーブロック、CDN ルール、またはエッジミドルウェアファイルの静的行であり、アプリケーションの変更も行動リスクもありません。 それらを分けるのは、デフォルトを蓄積する時間と、ブログ投稿、チェックリスト、フレームワークテンプレートがそれらを吸収した数です。 私たちは同じ形を、監査履歴全体で失敗したすべてのチェックをランク付けしたとき にも見ました：レスポンスヘッダーがリストのトップを支配し、正規化、レンダリング、パフォーマンスを上回ります。 そのランキングは別のウィンドウ、別のサンプル、そして以前のチェックセットをカバーしているため、二つのパーセンテージセットはトレンドラインではありません — しかし両方のトップにヘッダーが位置することは耐久的な発見です。
もう一つの構造的理由は不可視性です。 ヘッダーが欠落していても画面上には何も変わりません。 CMS は警告しません、ビルドは失敗しません、ダッシュボードは赤くなりません。 欠落は、原始的なレスポンスを検査するものにのみ観測可能です — それが監査、ブラウザのセキュリティ状態、そして増加する自動読者の共有です。 これは私たちが レンダーパリティ で見つけた同じ非対称性です：人間がブラウザで見るものと、機械が HTTP 経由で受信するものは静かに分岐しています。
各ヘッダーが保護するもの
Strict-Transport-Security は、ブラウザに対して指定された期間、あなたのドメインに対するプレーンテキスト HTTP を拒否するよう指示し、攻撃者がネットワーク上であなたの http:// → https:// リダイレクトが発火する前にハイジャックできるリダイレクトウィンドウを閉じます。 それはリスト上でコミットメントを持つ唯一のヘッダーでもあります：ブラウザは後で HTTPS を破っても max-age を尊重します。短く始め、すべてのサブドメインとアセットが TLS 上でクリーンに提供されることを確認し、次に拡張します。
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy は、スクリプト、スタイル、フレーム、および接続がどこから来るかを制限します。 ここで唯一、カテゴリを防止するのではなくインシデントを含むヘッダーは、タグマネージャーが侵害されたりユーザー入力が DOM に到達したときに、CSP が注入されたスクリプトが実行できるか、選択したサーバーに到達できるかを決定します。 それは作業中のページを壊す唯一のものでもあり、したがって以下のシーケンスの最後に配置されるべきです。
Content-Security-Policy-Report-Only: default-src 'self'
X-Frame-Options は、他のオリジンがあなたのページをフレームに入れることができるかどうかを宣言します。 それがなければ、あなたのインターフェースは攻撃者のページ上の透明なオーバーレイに埋め込まれ、ユーザーが自分があなたのサイトにいると信じてクリックできるようになります。 モダンな CSP は frame-ancestors でこれをよりよく表現します。古いクライアントはレガシーヘッダーしか読まないため、両方を配信してください。
X-Frame-Options: DENY
X-Content-Type-Options は、宣言された Content-Type が間違っているように見えるときに、ブラウザがレスポンスのタイプを推測するのを止めます。 スニッフィングは、テキストとして提供されるアップロードされたファイルがスクリプトとして実行される方法です。 ヘッダーには正確に 1 有効な値があります。
X-Content-Type-Options: nosniff
Referrer-Policy は、現在の URL のどれだけがアウトバウンドクリックとサブリソースロードで第三者に送られるかを管理します。 あなたの URL はキャンペーンパラメータ、内部検索クエリ、アカウント識別子、そして時にはトークンを持ち、ページ上のすべての分析ピクセルとフォント CDN は受信者です。 主なブラウザは合理的なデフォルトに収束していますが、デフォルトはユーザーエージェントがあなたのために行う決定であり、クライアントによって異なります。ヘッダーを送信すると、ポリシーが明示的になり、機密 URL を扱うサイトが same-origin のようにより厳格なものを選択できるようになります。
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy は、あなたのドキュメントと埋め込まれたフレームが要求できるブラウザ機能（カメラ、マイク、ジオロケーション、その他の強力な機能リスト）を決定します。 ヘッダーが欠如していると、無効にしていないすべてがページ上のすべてのスクリプト、書いていない第三者タグを含めて利用可能になります。 使用しないものを拒否してください。
Permissions-Policy: camera=(), microphone=(), geolocation=()
4 のワンライナーを最初に配信し、次に CSP に一日を費やしてください
保護の価値とデプロイリスクは正確に 1 ヘッダーで意見が分かれ、修正順序は配信に有利に解決します。
Diagram source
graph TD
A[自分のレスポンスヘッダーを読み取る] --> B[デプロイ 1: 短いmax-ageを持つHSTS]
B --> C[デプロイ 2: nosniff, リファラー・ポリシー, パーミッション・ポリシー, X-フレーム・オプション]
C --> D[TLS がすべてで確認されたら HSTS max-age を拡張する]
D --> E[CSPをレポートのみモードで実行]
E --> F{侵害レポートはクリーンです?}
F -->|いいえ| G[ソースを調整し、レポートのみを維持]
G --> F
F -->|はい| H[CSPを強制し、frame-ancestorsを追加]デプロイ 1 — HSTS、短い。 保護の価値が高く、サイトがすでにHTTPSをすべて提供している場合、リスクはほぼゼロです。 TLSの問題が忘れられたサブドメインで発生しても回復可能にするため、まずは控えめなmax-ageを設定します。
デプロイ 2 — 4つの静的なラインをまとめて。 nosniff、Referrer-Policy、Permissions-Policy、およびX-Frame-Optionsはアプリケーションの依存関係がない静的値です。 それらは6つのヘッダーのうちの4つであり、これらの失敗率では、平均的なサイトが欠けているものの大部分がです。 それらを別々に段階化する理由はありません。
その後HSTSを拡張し、 ドメイン下のすべてのホストがTLSでクリーンにサービスを提供していることを確認したら。
最後に — CSP、レポートのみモード。 Content-Security-Policy-Report-Onlyをデプロイし、実際のトラフィックから違反を収集し、実際に依存しているスクリプトと接続ソースを列挙します。 その後、ヘッダーを強制モードに切り替え、X-Frame-Options行とともにframe-ancestorsを追加します。 最高の労力で、シーケンスの最後に配置されるのは、リスト上で唯一作業中のページをダウンさせる可能性がある項目だからです。
1コマンドで自分のヘッダーを読み取ります
この測定はターミナルから再現可能です。リダイレクトを追跡してください。ブラウザが適用するのは最終レスポンスだからです：
curl -sSL -o /dev/null -D - https://example.com/ \| grep -iE 'strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'
戻ってこないすべての行は、ホームページが送信していないヘッダーです。 すべての6が戻ってくるということは、プレゼンスバーがクリアされ、次の質問 — ポリシー自体が良いかどうか — を尋ねる価値があることを意味します。 有料の SEOReport 診断 は、欠落している各ヘッダーとそれを解決する値をリストします。
このデータセットのヘッダーは、難しいまたは論争のあるために欠落しているわけではありません。 それらは、ウェブサイトの日常生活の中で欠落が表面化しないために欠落しています：エラーもなく、視覚的な変化もなく、ビルドも失敗しません。 合格したサイトは、誰かが一度探しに行った場所であり、その単一のデプロイはまだ多くの人に利用可能です。