このチェッカーの仕組み
なぜセキュリティヘッダーが必要か
HTTP 応答ヘッダーは、ブラウザに「このサイトではこう振る舞ってほしい」と伝える仕組みです。Content-Security-Policy はスクリプトの読み込み元を制限して XSS の被害を抑え、Strict-Transport-Security は平文の HTTP 接続をなくし、frame-ancestors は他サイトの iframe への埋め込み(クリックジャッキング)を防ぎます。アプリケーションのコードを直さなくても、サーバーや CDN の設定を数行足すだけで有効にできるため、費用対効果の高い対策として OWASP や MDN HTTP Observatory が推奨しています。
サーバーから 1 回取得し、保存しない
ブラウザは他サイトの応答ヘッダーを自由に読めないため、このツールは Cloudflare Workers 上のサーバーから入力 URL に GET 要求を送り、応答ヘッダーだけを読んで本文は捨てます。https:// を入力した場合は http:// からの転送を確認するためにもう 1 回、CORS ヘッダーがある場合は偽の Origin を付けて反射を確かめるためにもう 1 回アクセスします。リダイレクトは最大 10 回まで追い、各ホップの宛先を検査します。入力 URL も結果も記録しません。
15 項目を 4 段階で判定する
HTTPS への転送、HSTS、CSP、クリックジャッキング対策、X-Content-Type-Options、Referrer-Policy、Permissions-Policy、COOP / COEP / CORP、Cookie の属性、Cookie 付き応答のキャッシュ、廃止されたヘッダー、サーバー情報の露出、CORS の 15 項目を、適合 / 注意 / 要対応 / 未確認 の 4 段階で判定します。しきい値は OWASP の HTTP Headers Cheat Sheet と MDN HTTP Observatory の採点基準に合わせています。例えば HSTS の max-age は 6 か月(15552000 秒)未満を注意、CSP の script-src に 'unsafe-inline' があれば要対応です。
総合評価(グレード)は出さない
ヘッダーの重要度はサイトの性質で変わります。静的なブログに COEP は不要ですが、ログイン機能のあるサイトでは Cookie の属性が最優先です。A〜F の 1 文字はその違いを隠してしまうため、このツールは項目ごとの判定と、影響の大きい順に並べた「所見一覧」で示します。所見には影響と対処、出典を添えています。
不足分だけの修正例を出す
診断で不足または不十分だったヘッダーだけを、nginx / Apache / Cloudflare の _headers / Next.js / vercel.json / Express(helmet) の設定として書き出します。すでに設定済みのヘッダーは含めないため、そのまま追記できます。CSP は最小構成の例なので、実際に使う外部スクリプトや画像の読み込み元に合わせて調整してください。
この診断の限界
見ているのは、Cookie を持たない匿名アクセスで返る応答ヘッダーだけです。ログイン後のページ、HTML の meta タグで設定した CSP、JavaScript で動的に変わる挙動は確認できません。ヘッダーの整備はブラウザ側の防御を有効にする底上げであり、アプリケーションの脆弱性そのものを直すものではありません。結果は参考情報として、開発者ツールでの確認や脆弱性診断とあわせてお使いください。
メールのなりすまし対策(SPF / DKIM / DMARC)は、姉妹ツールのDMARC チェッカーで診断できます。
よくある質問
- なぜ A〜F のような総合評価(グレード)を出さないのですか
- ヘッダーの重要度はサイトの性質で変わります。静的なブログに COEP は不要ですが、ログイン機能のあるサイトでは Cookie の属性が最優先です。1 文字の評価はその違いを隠してしまうため、項目ごとの判定と、影響の大きい順に並べた所見一覧で示しています。
- 入力した URL にはどのようにアクセスしますか
- このサイトのサーバー(Cloudflare Workers)から、入力された URL に GET 要求を 1 回送り、応答ヘッダーだけを読みます。本文は読みません。https:// を入力した場合は http:// からの転送を確認するためにもう 1 回、CORS の設定がある場合は反射の確認にもう 1 回アクセスします。リダイレクトは最大 10 回まで追います。
- 入力した URL や結果は保存されますか
- 保存しません。入力 URL は診断のためにサーバーから 1 回アクセスし、結果はブラウザに返すだけで記録しません。診断後の URL(?url=...)を共有すると、開いた人のブラウザから再診断されます。詳しくはプライバシーポリシーをご覧ください。
- ログインが必要なページは診断できますか
- できません。このツールは Cookie や認証情報を持たずにアクセスするため、ログイン前のページ(多くはログイン画面)のヘッダーを評価します。ログイン後のページは、ブラウザの開発者ツールの Network タブで応答ヘッダーを確認してください。
- 内部ネットワークや localhost は診断できますか
- できません。SSRF(サーバーを踏み台にした内部アクセス)を防ぐため、localhost、プライベート IP アドレス、.local や .internal などのホスト名、標準以外のポート、ユーザー名付きの URL は拒否します。ホスト名が内部 IP に解決される場合や、リダイレクト先が内部の場合も途中で止めます。
- HTML の meta タグで設定した CSP は検出されますか
- 検出されません。このツールは HTTP 応答ヘッダーだけを見ます。<meta http-equiv> で設定した CSP は本文を読まないため見えず、また meta では frame-ancestors や report-uri が効かないため、ヘッダーで設定することを推奨します。
- Cloudflare や CDN を使っている場合、どの応答を見ていますか
- 利用者のブラウザと同じく、CDN を通った後の応答を見ています。CDN が付け外しするヘッダー(Server: cloudflare や CF-Ray など)も含まれます。オリジンサーバーだけの設定を確認したい場合は、CDN を経由しないホスト名で診断してください。
- 「要対応」を全部直せば安全ですか
- ヘッダーはブラウザ側の防御を有効にする仕組みで、アプリケーションの脆弱性そのものを直すものではありません。XSS や認可の不備があれば、ヘッダーで被害を小さくできても根本は残ります。ヘッダーの整備は「安く確実にできる底上げ」と考えてください。
判定基準と出典
判定は次の公式文書に基づきます。結果票の各項目の i アイコンからも参照できます。