本文へ移動
Develop Tools
← 使い方ガイドへ戻る

Webサイトのセキュリティヘッダーを確認する方法｜不足している設定をチェック

セキュリティヘッダーは「あるか」だけでなく、どの応答へどの値で付与され、ブラウザへ最終的に届いたかを確認します。

アプリからブラウザまでHTTPレスポンスヘッダーが届く流れ
アプリからブラウザまでHTTPレスポンスヘッダーが届く流れ

結論：最初に確認すること

まずHTML文書の最終レスポンスを取得し、Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options、X-Frame-Optionsまたはframe-ancestors、Referrer-Policy、Permissions-Policyを用途に照らして確認します。

確認対象はブラウザが受け取った最終レスポンスです。リクエストヘッダーとレスポンスヘッダーを混同せず、リダイレクトがある場合は各応答を分けて記録します。

実際のヘッダーを取得して確認する

Chrome DevToolsのNetworkで対象通信を選び、Response Headersをコピーします。CLIで確認する場合はcurl -Iまたはcurl -vを使い、取得した内容をそのまま解析ツールへ貼り付けます。

HTTP/2 200
content-security-policy: default-src 'self'
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
  • HTML文書とAPIを別々に確認する
  • HSTSはHTTPS応答で確認する
  • CSPは実際に必要な送信元と照合する
  • 不足表示を脅威モデルと照らして判断する

ヘッダーの役割と読み方

ヘッダーの有無だけではなく、値、適用対象、関連ヘッダーとの組み合わせを読みます。ページ本体、API、静的ファイルでは必要な設定が異なります。

確認項目役割読み方
CSP読み込めるリソースや埋め込み元を制限default-srcと個別directiveを確認
HSTS以後のHTTP接続をHTTPSへ限定max-age、includeSubDomains、対象ホストを確認
nosniffMIME sniffingを抑止正しいContent-Typeと組み合わせる
X-Frame-Options / frame-ancestors第三者サイトからの埋め込みを制御必要な埋め込み要件と照合
Referrer / Permissions / Cross-Origin参照元情報とブラウザ機能・分離を制御ページの機能要件と互換性を確認

よくある設定ミス

ヘッダー名だけを数えて点数化する、APIとHTMLへ同じ値を付ける、CDN導入前の応答だけを確認する、レポート専用CSPを強制適用と誤認する、といった確認では実際のブラウザ挙動を見落とします。

  • 設定ファイルでは存在するが公開レスポンスから消えている
  • リダイレクト応答と最終200応答で値が異なる
  • CDNキャッシュに変更前の値が残っている
  • 特定パスやエラーページだけ付与されていない

一つの推奨値を全ページへ機械的に適用すると、埋め込み、認証、外部リソース、API通信を壊す場合があります。段階導入と実測を優先してください。

Webサーバー・CDNを含めて切り分ける

設定ファイルが正しく見えても、公開応答では別の層が削除・上書きしていることがあります。アプリからブラウザまでを一段ずつ比較します。

層確認対象比較方法
Applicationアプリが付与するContent-Type、CORS、キャッシュ設定アプリ直結時の応答を保存する
Web ServerNginx・Apache・IISなどの追加、上書き、条件分岐設定対象のlocationや仮想ホストを確認する
Reverse Proxy転送時の削除、重複、リダイレクト応答プロキシ直後と公開URLの応答を比較する
CDNキャッシュ済みヘッダー、ルール、Worker処理キャッシュ消去後とパス別の応答を比較する
Browser最終応答、CORS判定、ポリシー適用DevToolsのResponse Headersで実測する

推奨値はサイト構成によって異なります。特にCSP、Permissions-Policy、COOP・COEP・CORPは機能を制限するため、Report-Onlyや検証環境を使って影響を確認してから強制します。

修正後に同じ条件で再テストする

修正後はHTML、API、静的資産、エラーページを確認し、ブラウザコンソールのCSP違反やCORSエラーも合わせて確認します。

  • 同じURL、HTTPメソッド、認証状態で再取得する
  • リダイレクト前と最終応答を分けて確認する
  • HTML、API、静的ファイルなどパスの種類を変えて確認する
  • CDNキャッシュを考慮し、変更前後の生ヘッダーを保存する

ツールの範囲と参考資料

HTTPヘッダー解析ツールは貼り付けたリクエスト・レスポンスをブラウザ内で解析し、機密値を初期状態でマスクします。URL欄は判定の文脈に使うだけで、対象サイトへの通信、リダイレクト追跡、脆弱性診断、点数評価は行いません。

資料URL確認できる内容
MDN HTTP Headershttps://developer.mozilla.org/docs/Web/HTTP/Reference/Headers各HTTPヘッダーの役割、構文、互換性
MDN CORShttps://developer.mozilla.org/docs/Web/HTTP/Guides/CORSOrigin、許可応答、資格情報付き通信の基本
OWASP Secure Headers Projecthttps://owasp.org/www-project-secure-headers/防御用レスポンスヘッダーの目的と運用上の注意
RFC 9110 HTTP Semanticshttps://www.rfc-editor.org/rfc/rfc9110HTTPフィールドと応答の意味に関する標準

実務的な確認例

本番と検証環境で同じパスのヘッダーを取得し、値の差を比較します。設定ファイルだけでなく、ブラウザへ届いた最終応答を証跡として残します。

修正は一度に一項目ずつ行い、DevToolsまたはcurlで再取得してから解析結果を更新します。

  1. 対象URLと確認時刻、環境を記録する
  2. リクエストとレスポンスを分けて保存する
  3. 解析ツールで警告理由と関連ヘッダーを確認する
  4. アプリ、Webサーバー、プロキシ、CDNのどこで付与するか決める
  5. 同じ条件で再取得して差分を確認する

Authorization、Cookie、Set-Cookie、APIキーなどは共有前に必ずマスクしてください。解析結果は安全性を保証するものではありません。

よくある質問

ヘッダーが不足していると表示されたら、すぐ脆弱性と判断できますか？
できません。用途、配信経路、ブラウザでの適用状況を確認するための手掛かりです。アプリの設計と脅威モデルに合わせて判断してください。
URLを入力するだけで公開サイトのヘッダーを取得できますか？
できません。DevTools、curl、サーバーログなどで取得したヘッダーを貼り付けるか、テキストファイルとして読み込んでください。入力はブラウザ内で解析されます。

ブラウザで試す

入力内容はブラウザ内で処理されます。元データを残したうえで、結果を確認してから保存・共有してください。

HTTPヘッダー解析ツールで確認する