CSPアナライザー

任意のURLのContent-Security-Policy（CSP）およびContent-Security-Policy-Report-Onlyを分析します。リスクのあるディレクティブ（unsafe-inline、ワイルドカード）、不足しているnonce/hash戦略、非推奨パターンを検出し、XSS防御を強化するための実用的な推奨事項を提供します。リダイレクト、生ヘッダー検査、フィルタリング、検出結果、JSON/PDFエクスポートをサポート。

Loading…

概要 CSPアナライザー

URLを貼り付けてCSPヘッダーを検査し、ポリシーが実際にXSSやインジェクションから保護されているかを素早く確認できます。このアナライザーは危険な許可（unsafe-inlineや広範なワイルドカードなど）を強調表示し、不足している要素（nonce/hash戦略、フレーム制限など）を説明し、report-onlyを安全に使用して実用的で導入可能なCSPへ移行する手助けをします。

機能

  • Content-Security-PolicyおよびContent-Security-Policy-Report-Onlyヘッダーの検出と説明。
  • 一般的なCSPの落とし穴（unsafe-inline、unsafe-eval、広範なワイルドカード、過度に寛容なソース）をフラグ付け。
  • nonceおよびhashベースの戦略による、より安全なスクリプト/スタイル実行のためのガイダンス。
  • 実世界の強化で重要な、不足しているディレクティブ（例：frame-ancestors、object-src、base-uri）の特定。
  • Report-Onlyの洞察：何がブロックされるか、本番環境を壊さずにCSPを展開する方法を理解。
  • リダイレクト（最大10回）を追跡し、ブラウザが適用する最終応答ポリシーを分析。
  • 正確なサーバー出力とデバッグのための生ヘッダービュー。
  • 検出結果とスコアカード、「問題のみ」フィルタリング機能。
  • 監査、チケット、セキュリティレビューのための分析結果をJSONまたはPDFにエクスポート。
  • 非推奨ヘッダーの認識を含み、レガシーポリシーと移行ニーズを捕捉。

🧭 使い方 for csp-analyzer

1

分析するURLを入力

チェックしたいページのURL（多くの場合、ホームページやアプリシェル）を貼り付けます。

2

必要に応じてリダイレクト追跡を有効化

「リダイレクトを追跡」を有効にし、実際のCSPが返される最終的なHTTPS/www/ロケールの宛先にアナライザーが到達するようにします。

3

スコアカードと検出結果を確認

まず検出結果から重大なリスク（unsafe-inline、ワイルドカード、不足している制限）を特定し、どのディレクティブがスコアに影響を与えているかを理解します。

4

デバッグ時には生ヘッダーを検査

「生ヘッダーを表示」をオンにして、正確なヘッダー名と値（複数のCSPヘッダーが存在する場合やプロキシ/CDNが変更した場合に有用）を確認します。

5

セキュリティワークフローのためにレポートをエクスポート

自動化のためのJSON、またはセキュリティ監査やエンジニアリングチケットのためのPDFをダウンロードします。

技術仕様

リクエストモデル

このツールはURLヘッダー検査を実行し、CSPおよびreport-onlyポリシーを含むセキュリティヘッダー分析に焦点を当てています。

設定動作デフォルト
リダイレクト追従リダイレクトチェーンを追跡し、最終URLが返す有効なポリシーを分析します有効
最大リダイレクト数ループを防ぐためのリダイレクト上限10
タイムアウトリクエストのタイムアウト制限15000 ms
ユーザーエージェントリクエストのユーザーエージェントを識別しますEncode64Bot/1.0 (+https://encode64.com)
プライベートネットワーク安全性のため、プライベートネットワーク範囲へのアクセスをブロックします無効（プライベートネットワークは許可されていません）

検査対象のCSPヘッダー

アナライザーは、強制ポリシーと非強制ポリシーの両方をチェックし、読みやすい形式で表示します。

ヘッダー意味
Content-Security-Policyブラウザによって適用される強制ポリシー
Content-Security-Policy-Report-Only違反を報告する非ブロッキングポリシー（展開と調整に有用）
サイトは複数のCSPヘッダーを出力する場合があります。ブラウザが適用する組み合わせ/優先順位のルールは複雑な場合があり、生のヘッダーは送信内容を確認するのに役立ちます。

分析が探すもの

所見は、実用的なCSP強化チェックと一般的な展開ミスに基づいています。

領域所見の例
スクリプトポリシーの強度unsafe-inline / unsafe-evalの使用、ワイルドカードソース、nonce/hash戦略の欠如
スタイルポリシーの強度unsafe-inlineスタイル、過度に広範なソース、可能な場合のnonce/hashへの移行パスの欠如
フレーミングとクリックジャッキング対策フレーム制限の欠如または弱さ（多くの場合frame-ancestors経由）
レガシー/非推奨パターン近代化すべき古いディレクティブやパターン
展開準備状況Report-Onlyポリシーの存在とレポートエンドポイントの可視性

コマンドライン

これらのコマンドを使用してCSPヘッダーを素早く検査できます。アナライザーのレポート内容を検証する際に便利です。

macOS / Linux

レスポンスヘッダーを取得（CSPを探す）

curl -I https://example.com

レスポンスヘッダー内のContent-Security-PolicyとContent-Security-Policy-Report-Onlyを検査します。

リダイレクトを追跡しながらヘッダーを確認

curl -IL https://example.com

最終的な宛先（HTTPS、www、アプリシェルルート）からのCSPヘッダーを確実に確認できます。

CSPヘッダーのみを表示（大文字小文字を区別しない）

curl -I https://example.com | grep -i "content-security-policy"

完全なヘッダーセットからCSPおよびレポート専用ヘッダーを素早く分離します。

Windows (PowerShell)

CSPヘッダーを検査

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

存在する場合、強制およびレポート専用のCSPヘッダーを表示します。

新しいポリシーはまずReport-Onlyで展開し、違反レポートを確認してから厳格化して強制適用します。CSPの調整は現代的なアプリケーションでは反復的なプロセスです。

ユースケース

XSSに対するサイトの強化

CSPを使用して、スクリプトやスタイルの読み込み元を制限し、インラインコードの処理方法を管理することで、インジェクション脆弱性の影響を軽減します。

  • unsafe-inline/unsafe-evalを特定し、nonce/hashへの移行計画を立てる
  • script-src/style-srcのソースを信頼できるオリジンに制限
  • 不足している防御的ディレクティブを追加（base-uri、object-src、frame-ancestors）

Report-OnlyでCSPを安全に展開

Content-Security-Policy-Report-Onlyから始めて違反を繰り返し調整することで、本番環境を壊すことなくCSPを段階的に導入します。

  • レポート専用ポリシーの存在を検出
  • 強制適用前に何がブロックされるかを理解
  • 展開計画とチケット用にレポートをエクスポート

壊れたスクリプト、iframe、またはサードパーティウィジェットのデバッグ

過度に厳格なCSPは、アナリティクス、埋め込みコンテンツ、またはAPI接続をブロックする可能性があります。アナライザーを使用して、ポリシーが許可する内容と明示的なソースが必要な箇所を確認します。

  • 許可されたscript/img/connect/frameソースを確認
  • 応急処置として追加された過度に広範なワイルドカードを検出
  • 広範な許可を対象ドメインに置き換え

セキュリティレビュー / コンプライアンス証跡

現在のCSPの状況について、セキュリティレビュー、クライアントアンケート、または内部コンプライアンス用に一貫したレポートを生成します。

  • 時間経過に伴う変更を追跡するためのJSONをダウンロード
  • 監査証跡と共有のためのPDFをダウンロード

❓ Frequently Asked Questions

❓CSPとは何ですか？何から保護しますか？

コンテンツセキュリティポリシー（CSP）は、ブラウザが強制するセキュリティレイヤーで、リソースの読み込み元やスクリプト/スタイルの実行方法を制限します。主にクロスサイトスクリプティング（XSS）やインジェクション攻撃の影響を軽減するために使用されます。

❓CSPとCSP Report-Onlyの違いは何ですか？

Content-Security-Policyは強制されます（ブロック可能）。Content-Security-Policy-Report-Onlyはブロックせず、違反を報告するため、ポリシーを強制する前に調整できます。

❓unsafe-inlineはなぜ危険とされるのですか？

unsafe-inlineはインラインスクリプト/スタイルを許可し、CSPが注入コードを阻止する能力を弱めます。より安全なアプローチでは、ナンスやハッシュを使用して既知のインラインブロックのみを許可し、予期しないインジェクションをブロックします。

❓ナンスやハッシュは必要ですか？

アプリがインラインスクリプトやスタイルを使用する場合、ナンス/ハッシュは機能を損なわずにCSPを効果的に維持する現代的な方法です。これらは特定のインラインブロックを許可しながら、任意のインジェクションを防ぎます。

❓CDNやプロキシはCSPヘッダーを変更できますか？

はい。エッジレイヤーはヘッダーを追加、統合、または上書きできます。不整合がある場合は、生ヘッダーを有効にし、リダイレクトを追跡して最終的なレスポンスヘッダーを確認してください。

❓CSPはXSSバグ修正の代替になりますか？

いいえ。CSPは多層防御の一環です。適切な出力エンコーディング、安全なテンプレート、入力検証は依然として必要です。CSPは何かがすり抜けた場合の被害範囲を縮小します。

❓ここにURLを貼り付けても安全ですか？

このツールは提供されたURLにサーバーサイドリクエストを行い、プライベートネットワークターゲットをブロックします。URLに秘密情報（クエリストリング内のトークンなど）を入れず、信頼できる公開URLを使用してください。

Pro Tips

Best Practice

Content-Security-Policy-Report-Onlyで開始し、違反を収集してから厳格化して強制します。CSPは実際のアプリでは反復的なプロセスです。

Best Practice

unsafe-inlineをナンスまたはハッシュ戦略に置き換えてください。ポリシーは明示的かつ最小限に保ちます。

Best Practice

frame-ancestorsを追加してクリックジャッキングのリスクを軽減し、レガシーヘッダーのみに依存しないようにします。

Best Practice

応急処置として広範なワイルドカードを避けてください。スクリプト/画像/接続には対象を絞ったドメインを優先し、サードパーティの必要性を確認します。

Best Practice

JSONレポートをエクスポートし、CSPの変更をCIで追跡して、CDN/アプリ更新時にヘッダーが変更された際のリグレッションを検出します。

Additional Resources

コンテンツセキュリティポリシー（MDN）
Documentation
Content-Security-Policyヘッダー（MDN）
Documentation
Content-Security-Policy-Report-Only（MDN）
Documentation
XSSガイド（OWASP）
Documentation
CSPチートシート（OWASP）
Documentation

Other Tools

CSPアナライザー — Content-Security-Policyおよびreport-onlyヘッダーの監査 | Encode64