サイトを壊さずにContent Security Policy (CSP)を導入する方法

Content Security Policy (CSP) がクロスサイトスクリプティング (XSS) やデータインジェクション攻撃からサイトを保護するために不可欠だと聞いたことがあるでしょう。しかし、いざ追加しようとするとサイトが壊れます。画像が消え、スクリプトが動かなくなり、スタイルが消えます。セキュリティと機能性のトレードオフのように感じられます。そうする必要はありません。

このガイドでは、サイトを壊さずにCSPを導入するための実践的なステップバイステップのアプローチを学びます。コアディレクティブ、nonceとハッシュの使い方、安全なテスト方法をカバーします。最後には、ユーザーエクスペリエンスを犠牲にすることなくセキュリティを強化する実用的なCSPが手に入ります。

CSPとは何か、なぜサイトを壊すのか？

Content Security Policyは、ページ上でどのリソース（スクリプト、スタイル、画像、フォントなど）を読み込めるかを制限できるブラウザのセキュリティ標準です。Content-Security-Policy: default-src 'self' のようなHTTPヘッダーで配信されます。

CSPがサイトを壊すのは、ポリシーに一致しないリソースをブロックするからです。インラインスクリプト、CDNからの外部スクリプト、インラインスタイルがある場合、明示的に許可しない限りブロックされます。デフォルトの動作は許可されていないものをすべてブロックするため、厳格なポリシーはすぐにサイトを壊す可能性があります。

鍵となるのは、許可的なポリシーから始めて、違反を監視しながら徐々に厳格にしていくことです。

知っておくべきコアCSPディレクティブ

CSPはディレクティブを使ってさまざまなリソースタイプを制御します。最も一般的なものは次のとおりです：

• default-src: 他のディレクティブのフォールバック。ここから始めます。
• script-src: JavaScriptのソースを制御します。
• style-src: CSSのソースを制御します。
• img-src: 画像のソースを制御します。
• connect-src: AJAX、WebSocket、fetchのターゲットを制御します。
• font-src: Webフォントのソースを制御します。
• frame-src: iframeのソースを制御します。
• report-uri / report-to: 違反レポートの送信先。

1つのヘッダーに複数のディレクティブをセミコロンで区切って設定できます。例えば：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com

各ディレクティブはスペース区切りのソースリストを受け入れます。ソースには 'self'、'unsafe-inline'、'unsafe-eval' のようなキーワード、URL、nonce/ハッシュなどがあります。

ステップバイステップ：サイトを壊さずにCSPを導入する

以下の手順に従ってCSPを安全に展開しましょう。

1. レポート専用ポリシーから始める。 強制ヘッダーの代わりに Content-Security-Policy-Report-Only ヘッダーを使用します。これにより、実際にブロックせずに何がブロックされるかを確認できます。
2. 許可的なポリシーを設定する。 default-src 'self' 'unsafe-inline' 'unsafe-eval' https: のように始めて、ほとんどのものを許可します。これで破損を最小限に抑えられます。
3. 違反レポートを収集する。 report-uri を違反をログに記録するエンドポイントに設定します。これらのレポートを確認してブロックされたリソースを特定します。
4. 違反を修正する。 インラインスクリプト/スタイルを避けるようにコードを更新するか、nonce/ハッシュを追加します。外部リソースを許可されたドメインに移動します。
5. ポリシーを徐々に厳格にする。 リファクタリングが完了したら 'unsafe-inline' と 'unsafe-eval' を削除します。許可するドメインを絞り込みます。
6. 強制モードに切り替える。 レポートに予期しないブロックが表示されなくなったら、ヘッダーを Content-Security-Policy（-Report-Only なし）に変更します。
7. 継続的に監視する。 新しい問題をキャッチするためにレポートエンドポイントをアクティブに保ちます。

この段階的なアプローチにより、セキュリティを向上させながらサイトを壊さないようにできます。

インラインスクリプトにnonceとハッシュを使用する

インラインスクリプトはCSP破損の一般的な原因です。'unsafe-inline' を許可する代わりに、nonce（1回限りの数値）またはハッシュを使用します。

Nonceアプローチ： リクエストごとにランダムなnonceを生成し、CSPヘッダーに追加し、スクリプトタグに含めます。

Content-Security-Policy: script-src 'nonce-abc123'

<script nonce="abc123">...</script>

ハッシュアプローチ： インラインスクリプトのSHAハッシュを計算し、ポリシーに追加します。

Content-Security-Policy: script-src 'sha256-xyz...'

ハッシュは頻繁に変更されない静的なインラインスクリプトに最適です。Nonceは動的コンテンツに適しています。

スタイルにもnonceやハッシュを使用できますが、nonce付きの style-src はインラインスタイル属性（例：style="..."）をカバーしないことに注意してください。それらには 'unsafe-inline' が必要か、クラスにリファクタリングする必要があります。

一般的なCSPディレクティブとその影響

ポリシーを構築する際のクイックリファレンスとしてこの表を使用してください。

CSPのテストと監視

強制する前に徹底的にテストします。ブラウザの開発者ツールを使用します：ConsoleタブにCSP違反がエラーとして表示されます。NetworkタブにCSPヘッダーが表示されます。

自動テストには、GoogleのCSP Evaluator（オンライン）や csp_evaluator npmパッケージなどのツールを検討してください。これらは弱いポリシーを特定するのに役立ちます。

本番環境で違反を収集するためのレポートエンドポイントを設定します。Report URIのようなサービスを使用するか、ファイルやデータベースにログを記録する独自のエンドポイントを構築できます。新しい問題をキャッチするために定期的にレポートを分析します。

覚えておいてください：CSPは万能薬ではありません。防御の1つの層です。入力検証、出力エンコーディング、その他のセキュリティベストプラクティスと組み合わせてください。

FAQ

Content-Security-PolicyとContent-Security-Policy-Report-Onlyの違いは何ですか？

強制ヘッダー（Content-Security-Policy）は違反をブロックします。レポート専用ヘッダー（Content-Security-Policy-Report-Only）はブロックせずに違反を報告するだけで、ポリシーを安全にテストできます。

onclickのようなインラインイベントハンドラでCSPを使用できますか？

いいえ、インラインイベントハンドラは 'unsafe-inline'（推奨されません）を使用するか、addEventListener を使用するようにリファクタリングしない限り、CSPによってブロックされます。より良いセキュリティのために、インラインイベントハンドラを避けてください。

CSPでGoogle Analyticsを許可するにはどうすればよいですか？

Google Analyticsのドメインを script-src と connect-src ディレクティブに追加します。例えば：script-src 'self' https://www.googletagmanager.com; connect-src 'self' https://www.google-analytics.com。最新の要件についてはGoogleのドキュメントを確認してください。

CSPの展開は苦痛なプロセスである必要はありません。段階的なアプローチにより、サイトを中断することなくユーザーをXSSやその他の攻撃から保護できます。レポート専用モードから始め、違反を修正し、時間をかけてポリシーを厳格にしていきます。

CSPレポート用のJSON設定ファイルを素早くフォーマットまたは検証する必要がある場合は、JSON Formatter を試して、JSONデータを整形してデバッグしてください。