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

URLの欠落またはリスクのあるセキュリティヘッダー（CSP、HSTS、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy、COOP/COEP/CORP）をチェックし、Cookieフラグ（Secure、HttpOnly、SameSite）を分析します。リダイレクトを最終宛先まで追跡し、JSON/PDFレポートをエクスポートし、実用的なハードニング推奨事項を取得します。

Loading…

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

現代のWebセキュリティは、主にHTTPレスポンスヘッダーによって強制されます。このツールはURLを取得し（オプションでリダイレクトを追跡）、XSS、クリックジャッキング、MIMEスニッフィング、安全でないトランスポート、クロスオリジン分離の問題を軽減する主要なハードニングヘッダーを監査します。また、Secure/HttpOnly/SameSiteの欠落、またはSecureなしのSameSite=Noneなどの一般的なギャップを検出するためにSet-Cookie属性を確認します。

機能

  • リダイレクトを追跡して最終的なHTTPS宛先を監査（実際のデプロイメントに推奨）。
  • 必要なハードニングヘッダーをチェック：Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options、X-Frame-Options、Referrer-Policy、Permissions-Policy。
  • 推奨される最新ヘッダーをチェック：COOP、COEP、CORP、Origin-Agent-Cluster、および存在する場合の追加のハードニングシグナル。
  • Set-CookieフラグのCookie分析：Secure、HttpOnly、SameSite；SecureなしのSameSite=Noneについて警告。
  • CSP分析：unsafe-inline、unsafe-eval、ワイルドカードソース、欠落している防御的ディレクティブ（default-src、object-src、base-uri、frame-ancestors）、およびreport-onlyの注意点を強調表示。
  • 非推奨またはリスクのあるヘッダー（例：X-XSS-Protection）および情報漏洩ヘッダー（例：Server、X-Powered-By）にフラグを立てます。
  • セキュリティレビュー、ペンテストレポート、またはバグチケット用のコピー/共有可能な調査結果。
  • 監査、コンプライアンス証拠、および回帰追跡用にJSONまたはPDFとしてレポートをダウンロード。

🧭 使用方法 for security-headers-checker

1

監査したいURLを貼り付け

完全なURL（できればhttps://…）を入力します。このツールは、そのエンドポイントによって返されるレスポンスヘッダーを評価します。

2

「リダイレクトを追跡」を有効にする（推奨）

多くのサイトはhttp→httpsおよびnon-www→www（またはその逆）にリダイレクトします。リダイレクトを追跡することで、ユーザーとボットが実際に到達する最終宛先を監査します。

3

生ヘッダーを表示するかどうかを選択

デバッグ用に元のヘッダー行が必要な場合は「生ヘッダーを表示」を有効にします（CDN、リバースプロキシ、フレームワークのデフォルトに最適）。

4

調査結果を確認し、修正を優先順位付け

まず、トランスポートセキュリティ（HSTS）、XSS対策（CSP）、クリックジャッキング対策（フレーム保護）、Cookieフラグ、および該当する場合はクロスオリジン分離（COOP/COEP/CORP）に焦点を当てます。

5

追跡用にレポートをエクスポート

JSON/PDFをダウンロードしてチケットに添付し、時間の経過に伴う変更を比較するか、回帰検出のためにCIにチェックを追加します。

技術仕様

このツールがチェックするもの

このチェッカーは、ブラウザーによって強制されるセキュリティ制御に使用される、最新の高影響力のレスポンスヘッダーとCookie属性に焦点を当てています。

領域チェックされるシグナル重要性
トランスポートセキュリティStrict-Transport-Security (HSTS)HTTPSを強制し、以降の訪問でのSSLストリッピング攻撃を防ぎます。
XSS対策Content-Security-Policy (CSP) + よくある落とし穴スクリプトやスタイルのソースを制限し、正しく設定されていればXSSの影響を軽減します。
クリックジャッキングX-Frame-Options および/または CSP frame-ancestors他のオリジンによってページがフレーム化されるのを防ぎます。
MIMEスニッフィングX-Content-Type-Options: nosniffブラウザが危険な方法でコンテンツタイプを推測するのを防ぎます。
リファラ漏洩Referrer-Policy他のサイトに送信されるリファラ情報の量を制御します。
権限制御Permissions-Policy強力な機能（カメラ、マイク、位置情報など）をブラウザレベルで制限します。
クロスオリジン分離COOP / COEP / CORP（および関連）高度なセキュリティ分離と一部の高性能APIに必要です。
クッキーSet-Cookieフラグ: Secure, HttpOnly, SameSiteセッション盗難のリスクを低減し、正しく設定されていればCSRFを軽減します。
危険/非推奨X-XSS-Protection, Server, X-Powered-By（存在する場合）非推奨の制御や、攻撃者を助ける可能性のある情報漏洩です。

リクエスト動作と制限

監査はサーバー側で実行され、実際のナビゲーション動作に合わせてリダイレクトを追従できます。

設定動作デフォルト
リダイレクトを追従上限数までのリダイレクトを追従します有効
最大リダイレクト数追従が有効な場合の最大リダイレクト数10
タイムアウトリクエストタイムアウト15000 ミリ秒
ユーザーエージェントリクエスト識別ヘッダーEncode64Bot/1.0 (+[https://encode64.com](https://encode64.com))
プライベートネットワークプライベートネットワークターゲットをブロック許可されていません

結果の正しい解釈

「合格」のヘッダースキャンは「安全」と同じではありません。ヘッダーは一つの層です。目標は、一般的な問題クラスの影響範囲を縮小し、より安全なブラウザのデフォルトを強制することです。

このレポートをベースラインの強化チェックリストとして使用してください。認証、認可、入力検証、依存関係の脆弱性、サーバー設定の監査は引き続き行ってください。

コマンドライン

curlを使用してチェッカーが行うことを再現し、デバッグやCI中にヘッダーを迅速に検証します。

macOS / Linux

レスポンスヘッダーを取得

curl -I [https://example.com](https://example.com)

エンドポイントから返されるトップレベルのヘッダーを表示します。

リダイレクトを追跡してヘッダーを表示

curl -IL [https://example.com](https://example.com)

リダイレクト後の最終的な宛先ヘッダーを確認するのに便利です。

Set-Cookie行を検査

curl -sI [https://example.com](https://example.com) | grep -i '^set-cookie:'

Secure/HttpOnly/SameSite属性の確認に役立ちます。

Windows (PowerShell)

レスポンスヘッダーを取得

(Invoke-WebRequest -Uri [https://example.com](https://example.com) -Method Head).Headers

PowerShellで返されたヘッダーを出力します。

HTMLページと重要なAPIエンドポイントの両方を必ずテストしてください：これらは多くの場合、異なるミドルウェアスタックを持っているため、異なるヘッダーセットになります。

ユースケース

Webアプリケーションのセキュリティ強化ベースライン

最小限のヘッダーベースラインを確立し、デプロイメント、プロキシ/CDNの変更、またはフレームワークのアップグレード後に欠落しているヘッダーを検出します。

  • 本番環境のHTTPSにHSTSが存在することを確認
  • 認証済みページでクリックジャッキング保護が有効になっていることを確認

クッキーとセッションの安全性レビュー

セッションクッキーがSecure/HttpOnly/SameSiteで送信されていることを検証し、一般的な設定ミスを検出します。

  • SecureなしのSameSite=Noneを検出
  • セッショントークンにHttpOnlyが設定されていることを確認

CSP品質とXSSリスク低減

高リスクなCSPパターンを特定し、XSS影響を実質的に軽減する修正を優先します。

  • unsafe-inlineを削除し、nonce/hash戦略を採用する
  • より強力なデフォルト設定のためにframe-ancestorsとbase-uriを追加する

CDN / リバースプロキシのリグレッションチェック

CDN、ロードバランサー、またはプロキシがヘッダーを削除または複製するタイミングを検出します。

  • Cloudflare/Varnish/Nginxの変更後もセキュリティヘッダーが維持されていることを確認する
  • リダイレクトが最終宛先でHSTSを削除しないようにする

❓ Frequently Asked Questions

❓セキュリティヘッダーはなぜ重要ですか？

これらは、XSS、クリックジャッキング、混合コンテンツやダウングレード問題などの一般的なWeb攻撃の影響を軽減するブラウザ側のセキュリティ制御を強制します。また、クッキーやクロスオリジン動作に対してより安全なデフォルトを設定します。

❓「リダイレクトをフォロー」を有効にするべきですか？

通常ははい。実際のユーザーやクローラーはリダイレクト後に最終URLに到達し、そこで有効なヘッダーが重要になります。リダイレクトチェーンは、最終宛先で欠落しているヘッダーを隠してしまう可能性があります。

❓CSPはすべてのサイトに必要ですか？

ユーザーセッションや動的コンテンツがあるサイトには強く推奨されます。基本的なCSPでもXSSリスクを軽減できますが、スクリプトやサードパーティ統合を壊さないよう注意深くテストする必要があります。

❓X-XSS-Protectionが非推奨またはリスクありとフラグ付けされるのはなぜですか？

現代のブラウザでは時代遅れであり、一部の過去のケースでは予期しない動作を引き起こす可能性があります。代わりにCSPと安全なコーディング手法に焦点を当ててください。

❓よくあるHSTSの間違いは何ですか？

HTTPSでHSTSを有効にしながら、HTTPSを一貫して提供するのを忘れる（または正規ホストで見落とす）ことです。もう一つのよくある間違いは、プリロード要件を完全に満たさずにプリロードディレクティブを追加することです。

❓ヘッダーだけでアプリケーションを保護できますか？

いいえ。ヘッダーは強化レイヤーです。安全なコーディング、依存関係管理、認証/認可の正確性、堅牢なサーバー設定は依然として必要です。

Pro Tips

Best Practice

ランディングHTMLとAPIエンドポイントの両方を監査してください。これらは異なるミドルウェアを持つことが多く、ヘッダー適用範囲が静かに分岐する可能性があります。

CI Tip

リダイレクトチェーンチェックを実行する：最終宛先が最も強力なヘッダー（特にHSTSとCSP）を設定していることを確認します。

Best Practice

クッキーはセキュリティ境界の一部として扱いましょう：セッションクッキーには、Secure + HttpOnly + 適切なSameSiteをデフォルト設定にすべきです。

Best Practice

CSPでは、unsafe-inline/unsafe-evalの削除と、nonceやハッシュの採用を優先しましょう。これは通常、実運用で最も大きなセキュリティ向上をもたらします。

Best Practice

サーバーの詳細情報を漏らさないようにしましょう。可能な限りServer / X-Powered-Byヘッダーを削除または最小化し、フィンガープリンティングのリスクを軽減します。

Best Practice

CIに回帰テストを追加し、重要なヘッダーが消失した場合にデプロイを失敗させましょう（プロキシやCDNの変更による予期せぬ消失は、思った以上に頻繁に発生します）。

Additional Resources

OWASP セキュアヘッダープロジェクト
Documentation
MDN: コンテンツセキュリティポリシー (CSP)
Documentation
MDN: Strict-Transport-Security (HSTS)
Documentation
MDN: Set-Cookie
Documentation
MDN: Permissions-Policy
Documentation

Other Tools