セキュリティヘッダー解説
セキュリティヘッダーは HTTP レスポンスの 1 行であり、訪問者のブラウザがあなたのページに対してできることを変えます：名前を挙げたソースからのみスクリプトを実行する、二度と平文 HTTP で話さない、フレームに埋め込まれることを拒否する、コンテンツタイプを推測しない。どれもコードも、ライブラリも、再起動も必要ありません——それでもほとんどのウェブサイトはほとんど、あるいはまったく送信しておらず、だからこそスキャナがチェックするとほとんどのサイトが F になります。この記事では、ヘッダーごとにそれぞれが実際に何を止めるのかを順に説明し、F の蔓延を解説し、作業 1 時間あたり最も多くの保護を取り戻す修正順序を示します。自分のサイトの判定を見るには、まずセキュリティヘッダーチェックを実行し、結果を開いたまま読み進めてください。
ヘッダーはブラウザへの指示であり、サーバーの鎧ではない
まず、ヘッダーが何でないかから始めましょう。セキュリティヘッダーはアプリケーションにパッチを当てず、トラフィックをフィルタせず、誰も認証しません。それはサーバーがレスポンスに添付する宣言であり、ブラウザ——訪問者のブラウザ、訪問者のマシン上にある——がその瞬間からそれを強制します。多くの攻撃が攻撃者に代わってブラウザによって実行されることに気づくまでは、これは弱く聞こえます：誰かがコメント欄に注入したスクリプトを実行する、敵対的なサイト上の見えないフレームの中にログインページを読み込む、内容がスクリプトらしく見えるという理由でアップロードされたテキストファイルを HTML として扱う。ヘッダーは、サーバーがブラウザに事前に伝える方法です——このサイトでは、それらの動きは決して正当ではない、と。
ヘッダーは多層防御でもあり、そのように読むべきです。この分野の標準的な参照は、各ヘッダーの構文と意味を規定する MDN HTTP ドキュメントと、OWASP Web セキュリティテストガイドのテスト指針が指し示す推奨値を持つ OWASP Secure Headers Project です。どちらの情報源も、ヘッダーがサイトを安全にするとは約束しません。約束するのはもっと狭く、真実であることです：ヘッダーが設定されていれば、アプリケーションのバグが攻撃者に足場を与えた場合でも、ブラウザが実行する攻撃のクラス全体が機能しなくなります。
各ヘッダーが実際に何を止めるのか
Content-Security-Policy は注入されたスクリプトの実行を止めます。XSS とその近縁——スクリプトを抱えた保存済みコメント、侵害されたサードパーティタグ経由で注入されたスキミングスクリプト——はすべて、サイトが意図しなかったコードをブラウザが実行することを必要とします。CSP は許可リストです：script-src がスクリプトの出所としてよいオリジンを名指しし、インラインスクリプトや攻撃者のサーバーから読み込まれるものを含むその他すべては拒否されます。その弱い形は有名です：'unsafe-inline' を含むポリシーは、注入されたものを含むすべてのインラインスクリプトを実行させてしまいます。だからこそチェッカーはそのようなポリシーを「良い」ではなく「弱い」と扱います。CSP は導入が最も重いヘッダーであり、最も多くを止めるヘッダーです。
Strict-Transport-Security はダウングレードを止めます。訪問者が初めてスキームなしでドメインを入力したり、古い http:// リンクをたどったりすると、そのリクエストは平文でネットワークを横断し、途中で剥ぎ取られたり、リダイレクトされたり、読まれたりする可能性があります——セッション Cookie も含めて。HSTS はブラウザに伝えます：次の max-age 秒の間、このホストのすべての http:// URL を、何もマシンを離れる前に https:// に書き換え、証明書エラーのクリック通過を拒否せよ、と。誠実な限界が 1 つ：HSTS は、ブラウザがそのヘッダーをすでに 1 回見たことのある訪問者だけを保護します（ブラウザに組み込まれたプリロードリストは、まさにその初回訪問の隙間を埋めるために存在します）。そして HSTS 自身が HTTPS で届いたときにだけ尊重されます。
フレーム保護はクリックジャッキングを止めます。あなたのページがフレームに埋め込める場合、敵対的なサイトはあなたの本物のインターフェースを自前のボタンの透明な層の下に敷き、クリックを収穫できます——被害者は無害そうなページを見て、送金を承認してしまいます。CSP ディレクティブ frame-ancestors（とその先輩である X-Frame-Options: DENY または SAMEORIGIN）は、誰があなたをフレームに入れてよいかを名指しします；それ以外の全員には空のフレームが返ります。X-Content-Type-Options: nosniff はもっと静かな手口を止めます：ブラウザは歴史的に、宣言された Content-Type を推測し直し、内容がそれらしく見えるとファイルをスクリプトや HTML として実行し、無実のアップロードを保存型 XSS に変えてきました。nosniff は推測を終わらせます——宣言されたタイプがタイプです。
Referrer-Policy は URL の漏洩を止めます。訪問者があなたのページから別のサイトへクリックすると、ブラウザは歴史的に、あなたのページの完全な URL を Referer として送信してきました——その中に座っているパスワードリセットトークン、検索語、レコード ID も含めて。strict-origin-when-cross-origin かそれより厳しいポリシーは、クロスサイトではオリジンだけを送り、ダウングレードしやすい http の宛先には何も送りません。Permissions-Policy は機能の乱用を止めます：このサイトがそもそもどの強力なブラウザ機能——カメラ、マイク、位置情報、支払いハンドラ——を使ってよいかを宣言するので、注入されたフレームやスクリプトがあなたの名でそれらを静かに要求できなくなります。そしてボーナスヘッダーである Cross-Origin-Opener-Policy は、あなたのページとクロスオリジンのポップアップの間の window.opener リンクを断ち、あなたのブラウジングコンテキストを、それを探ろうとするページから隔離します。
なぜこれほど多くのサイトが F なのか
誰のデフォルトもこれらのヘッダーを送信しないからです。素の Web サーバー、素のフレームワークの雛形、素の静的ホスト：どれも 6 つのうち最大で 1 つか 2 つだけを含むレスポンスを送り、最も価値のある 2 つ——CSP と Permissions-Policy——は具体的なサイトについての判断を必要とするため、どのデフォルトも安全には同梱できません。責任はその後 3 つに割れます：フレームワークチームはサーバーがヘッダーを加えるものと思い、サーバーチームはフレームワークが加えるものと思い、前にある CDN はとにかく好きなように書き換えます。ヘッダーはその隙間から静かに落ちます。なぜなら、それらがなくても目に見えて壊れるものは何もないからです。F のサイトは通常、A のサイトとまったく同じに見え、同じように動作します；違いが現れるのは、攻撃がブラウザの協力を必要とするその日だけです。
公表された数字はその話と一致します。2026-11-04 の週刊ツールスキャン総括で報じられた、あるスキャナの公表サンプルでは、スキャンされたサイトの 65% が F、51% が Content-Security-Policy をまったく送信していないことが分かりました。これらは本来の姿として扱ってください——あるスキャナのサンプルであり、第三者によって公表されたもので、ウェブ全体の測定でも、私たち自身のデータでもありません——しかし方向性はあらゆる運用者の経験と一致します：ヘッダーは、その不在が統計的な常態である珍しいセキュリティ管理策なのです。それはこの統計に隠れた良い知らせでもあります：バーは床にあり、それを越えるのはエンジニアリングではなく設定です。
修正順序：1 時間あたりの影響で
セキュリティヘッダーチェックが明白にする順序で作業してください。まず、1 行で済むもの：X-Content-Type-Options: nosniff、フレーム保護、そして妥当な Referrer-Policy——100 点のうち 35 点、数分の作業、そして通常のサイトでは破損リスクは実質ゼロです。次に HSTS——さらに 20 点——ただし、すべてのページ、サブドメイン、レガシーなリダイレクトが本当に HTTPS で動作することを確認した後に限ります。長い max-age は取り消せないからです。3 番目に Permissions-Policy：サイトが実際に使う機能を挙げ、それ以外を無効にしてください；丁寧な 1 行で 10 点です。
最後に、そしてゆっくりと、CSP。その 35 点は最大の単一ブロックであり、自分のサイトを倒しかねない唯一の修正です。まず報告エンドポイント付きの Content-Security-Policy-Report-Only として導入し、1 週間分の違反報告を読み、それが指し示すインラインスクリプトとイベントハンドラを書き直し——あるいは MDN の指針が勧めるように nonce を採用し——報告が静かになってから初めて強制に切り替えてください。クロスオリジンのポップアップフローに依存していない限り、Cross-Origin-Opener-Policy: same-origin を加えてください；私たちの表では無採点ですが、安い隔離です。その後チェックを再実行し、オリジンで加えたヘッダーが、その前にある CDN とプロキシを本当に生き残ったか確認してください。
ヘッダーにできないこと
ヘッダーは穴を直すことはできません。攻撃者がその穴を通してできることを小さくするだけです。CSP は入力のエスケープに失敗したコメント欄を直しません；注入されたペイロードが実行を拒むようにするだけです。HSTS は壊れた証明書チェーンを直しません——それは SSL グレーダーの領分です——そしてどのヘッダーも、パッチ適用、バックアップ、アクセス制御の代わりにはなりません。完璧なヘッダーのグレードは、他の階がそれぞれのチェックをまだ必要とする建物の、しっかり施錠された扉として読んでください。それこそが ウェブサイトヘルスチェックの用途です。
ヘッダーはまた、設定して忘れることもできません。昨年のサイトのために書かれた CSP は、今年の支払いウィジェットを静かにブロックします——あるいはもっと悪く、慌てて * で緩められ、何も意味しなくなります。ヘッダーの集合は、あなたの設定の残りと同じように扱ってください：バージョン管理され、サイトが変わるときに見直され、プラットフォームの変更のたびに再チェックされる。チェックは 10 秒で終わります；ページの前にあるスタックが変わるたびに実行すれば、F の蔓延は誰か他の人の統計のままです。