セキュリティヘッダーチェッカー

サイトのURLを入力するだけで、HSTS・CSP・X-Frame-Optionsなど主要なセキュリティヘッダーの設定状況を診断します。不足しているヘッダーや設定が甘い項目を一覧表示し、改善のヒントも確認できます。

公開サイトのセキュリティヘッダーを診断する

URLを入力すると、サーバー側がそのサイトへアクセスしてレスポンスヘッダーを取得し、HSTS・CSP・X-Frame-Options・X-Content-Type-Options・Referrer-Policy・Permissions-Policy の設定状況を判定します。不足しているものと、設定はあるが弱いものを分けて示し、それぞれ何が問題になるかを添えます。

**ここで意識しておきたいのは、ヘッダーが「ある」ことと「効いている」ことは別だという点です。** たとえば HSTS は付いていても `max-age` が短ければブラウザが HTTPS を強制する期間が足りず、実質的な保護は薄くなります。このツールが合格と警告を分けているのはそのためです。**もう一つ、返ってきたヘッダーは必ずしもオリジンのサーバーが付けたものとは限りません。** CDN やリバースプロキシが途中で付与している場合があり、その場合は設定を直すべき場所も変わります。診断結果は「外から見えている状態」であって、どの層が付けたかまでは分かりません。

使い方

  1. 対象のURLを入力する `https://` から始まる公開されているURLを入れます。
  2. チェックを実行する **プライベートIPアドレス等、外部から到達できない宛先は安全のため拒否されます。**
  3. 判定を読む 合格・警告・不合格の3段階で示され、警告は「あるが弱い」状態を意味します。
  4. 説明を手がかりに直す 各項目に何が問題かが添えられているので、設定の優先順位を決められます。

使いこなすためのヒント

  • このツールは対象サイトのURLをサーバー側で取得するため、ブラウザのCORS制限を受けずどのサイトのヘッダーも診断できます。
  • HSTSのmax-ageは基本的に長いほど安全ですが、証明書運用を見直す予定がある場合は事前に短い値でテストしてから本番反映しましょう。
  • 姉妹ツールのCSPバリデーターと組み合わせると、Content-Security-Policyの構文まで詳細に検証できます。
  • robots.txtチェッカーと同じ「URLを入力してサーバー側で取得する」仕組みを採用しているため、認証不要な公開ページであればどのサイトも診断対象にできます。
  • 定期的に自社サイトをチェックし、CDNやリバースプロキシの設定変更でセキュリティヘッダーが意図せず消えていないか確認する習慣をつけましょう。

活用シーン

公開前の最終確認をする

リリース直前に、意図したヘッダーが実際に返っているかを外から確かめられます。

他社サイトの設定を参考にする

**同業のサイトがどこまで設定しているかを見ると、自社の水準を測る目安になります。**

設定変更の前後を比べる

ヘッダーを足した後に再度チェックして、反映されているかを確認できます。

引き継いだサイトを点検する

**運用を引き継いだ直後の棚卸しに向きます。** 何が抜けているかを一覧で把握できます。

セキュリティヘッダーの用語

HSTS
HTTPでのアクセスをHTTPSへ強制する指定です。**`max-age` が1年以上でないと保護の期間が足りません。**
X-Content-Type-Options
`nosniff` を指定すると、ブラウザが内容からMIMEタイプを推測するのをやめます。誤った実行を防ぎます。
X-Frame-Options
自サイトを frame に埋め込ませない指定です。**新しくは CSP の `frame-ancestors` が同じ役割を担います。**
Content-Security-Policy
読み込んでよい資源の出所を制限する仕組みです。XSSへの防御の中心になります。
Referrer-Policy
別サイトへ遷移するときに、どこまで参照元URLを渡すかを決める指定です。
Permissions-Policy
カメラ・マイク・位置情報などの機能を、どのオリジンに許すかを制御する指定です。

よくある質問

機能面では近い診断を提供しますが、Toolbaseのチェッカーは日本語で結果と改善理由を確認できる点が異なります。詳細なCSP構文チェックは姉妹ツールのCSPバリデーターと役割分担しています。

使えますが、HSTSはHTTPS接続にのみ意味を持つヘッダーのため、HTTPのみのサイトではHSTSの項目は常に不合格と診断されます。まずはサイト全体のHTTPS化を優先してください。

現在はContent-Security-Policyのframe-ancestorsディレクティブが推奨されますが、対応していない古いブラウザも存在するため、両方を併記して二重に対策するのが実務上の定石です。

いいえ。入力されたURLへのリクエストはその場限りで行われ、取得したヘッダー情報をサーバー側に保存することはありません。

必ずしもそうとは限りません。特にPermissions-Policyは必須ではない追加の防御層であり、サイトの性質によっては優先度が低い場合もあります。まずはHSTS・CSP・X-Frame-Optionsなど影響の大きい項目から改善することをおすすめします。
ツールくん

余談ですが ― securityheaders.comと、クリックジャッキング対策の歴史

HTTPレスポンスヘッダーによるセキュリティ設定の診断は、Scott Helme氏が開発した「securityheaders.com」が長年デファクトスタンダードとして知られています。海外製のサービスは診断結果や改善理由の説明が英語のみのことが多く、Toolbaseではこの分野の代替として、日本語で結果と改善理由をまとめて確認できる自前のチェッカーを用意しました。

HSTS(HTTP Strict Transport Security)は2012年にIETFがRFC 6797として標準化したヘッダーです。背景には、ユーザーがhttps://を省略して手入力した際に一度だけHTTPで接続してしまい、その一瞬を狙って通信を書き換える「SSL Stripping」という攻撃が2009年に実演されたことがあります。HSTSはブラウザに「このドメインは常にHTTPSでアクセスする」と記憶させることで、初回以降のダウングレード攻撃を防ぎます。

X-Frame-Optionsは2009年にMicrosoftがInternet Explorer 8向けに導入した独自拡張ヘッダーで、後に他ブラウザにも採用されデファクトスタンダード化しました。当時問題視されていたのは「クリックジャッキング」と呼ばれる攻撃で、透明なiframeを本物のボタンの上に重ね、ユーザーに気づかれないままクリックさせる手口でした。現在はより柔軟に指定できるContent-Security-Policyのframe-ancestorsディレクティブへの移行が進んでいますが、対応していない古いブラウザ向けの保険として、両方を併記することが今も推奨されています。