現代のウェブサイト運営において、セキュリティ対策は避けては通れない非常に重要な課題となっています。

特に、悪意のあるスクリプトをサイトに埋め込む「クロスサイトスクリプティング（XSS）」は、長年にわたりウェブサイトを脅かす主要な攻撃手法の一つです。

このような攻撃からユーザーを守り、サイトの安全性を高めるための強力な仕組みがコンテンツセキュリティポリシー（CSP）です。

CSPを正しく理解して導入することで、万が一アプリケーションに脆弱性が存在していたとしても、被害を最小限に抑えることが可能になります。

本記事では、CSPの基本的な仕組みから具体的な設定方法、運用上の注意点までを詳しく解説します。

目次 [ close ]
  1. コンテンツセキュリティポリシー（CSP）とは何か
    1. CSPが登場した背景と目的
  2. CSPがXSSを防ぐ仕組み
  3. 主なCSPディレクティブの種類
  4. CSPの具体的な設定方法
    1. HTTPヘッダーによる設定
    2. metaタグによる設定
  5. 安全にCSPを導入するためのステップ
    1. 1. Report-Onlyモードの活用
    2. 2. 違反レポートの分析と修正
    3. 3. 強制（Enforce）モードへの移行
  6. インラインスクリプトの扱いと「Nonce」の仕組み
  7. CSP導入時の注意点と課題
  8. まとめ

コンテンツセキュリティポリシー（CSP）とは何か

コンテンツセキュリティポリシー（CSP）は、ウェブサイトで読み込みを許可するリソースのソースを、ブラウザに対して指示するためのセキュリティレイヤーです。

通常、ブラウザはHTML内に記述されたスクリプトや画像などのリソースを、その提供元に関わらず読み込んで実行しようとします。

しかし、CSPを設定することで、「どのドメインからのスクリプトなら実行して良いか」や「どのサーバーへのデータ送信を許可するか」といったルールを厳格に定義できます。

CSPは、ブラウザが備えているセキュリティ機能を最大限に活用し、予期しないコードの実行を防ぐための強力な盾として機能します。

主要なモダンブラウザのほとんどがCSPに対応しており、現在ではウェブアプリケーションの防御に欠かせない標準的な技術となっています。

CSPが登場した背景と目的

CSPが開発された背景には、クロスサイトスクリプティング（XSS）攻撃の深刻化があります。

XSSは、攻撃者がウェブページに不正なスクリプトを注入し、ユーザーのクッキーを盗み出したり、偽の情報を表示させたりする攻撃です。

開発者がどれほど注意深くコードを書いていても、複雑なウェブサイトのすべての箇所で脆弱性を完全になくすことは容易ではありません。

そこで、脆弱性があることを前提として、「不正なコードが注入されても実行させない」という多重防御の考え方からCSPが誕生しました。

CSPの主な目的は、信頼できるソースのみを定義することで、攻撃者が注入した外部スクリプトの実行や、インラインスクリプトによる攻撃を無効化することにあります。

CSPがXSSを防ぐ仕組み

CSPの動作原理は、非常にシンプルでありながら強力なホワイトリスト方式に基づいています。

ウェブサーバーは、ブラウザに対してレスポンスを返す際に、Content-Security-PolicyというHTTPヘッダーを付与します。

ブラウザはこのヘッダーの内容を解釈し、指定されたポリシーに従ってリソースの読み込みを制御します。

例えば、ポリシーで特定のドメイン以外からのスクリプト読み込みを禁止している場合、攻撃者が外部から読み込ませようとしたスクリプトはブラウザによって即座にブロックされます。

また、CSPはデフォルトで「インラインスクリプト（HTML内に直接書かれたスクリプト）」の実行を禁止する機能を持っています。

多くのXSS攻撃はHTMLタグの中にスクリプトを埋め込む手法を用いるため、この制限だけでも極めて高い防御効果を発揮します。

さらに、eval()関数のような文字列をコードとして実行する関数の利用も制限することができ、コードの不正実行ルートを徹底的に塞ぎます。

主なCSPディレクティブの種類

CSPでは、リソースの種類ごとに「ディレクティブ」と呼ばれる項目を設定して、制限の範囲を細かく指定します。

代表的なディレクティブを理解することで、より緻密なセキュリティポリシーを構築できるようになります。

ディレクティブ説明
default-src他のディレクティブで個別に指定がない場合のデフォルトのフォールバック先を定義します。
script-srcJavaScriptの読み込みおよび実行を許可するソースを指定します。
style-srcCSS（スタイルシート）の読み込みを許可するソースを指定します。
img-src画像の読み込み元を許可するソースを指定します。
connect-srcXMLHttpRequestやFetch API、WebSocketなどの接続先を制限します。
frame-ancestors自サイトをiframeなどに埋め込むことを許可する親サイトを指定し、クリックジャッキングを防ぎます。

これらのディレクティブを組み合わせることで、サイトの特性に合わせた最適なポリシーを構築できます。

基本的には、まずdefault-src 'self';を設定し、サイト自身のドメインのみを許可することから始めるのが一般的です。

CSPの具体的な設定方法

CSPを設定する方法には、大きく分けて2つの手法が存在します。

最も推奨される方法は、サーバー側からHTTPレスポンスヘッダーを送信する方法です。

もう一つは、HTMLの<meta>タグを使用する方法ですが、こちらは一部の機能が制限される場合があります。

HTTPヘッダーによる設定

ApacheやNginxなどのウェブサーバーの設定ファイル、またはウェブアプリケーションのミドルウェアを通じてヘッダーを出力します。

以下は、自身のサイトと信頼できる外部ドメイン（example.com）からのスクリプトのみを許可する場合のヘッダー例です。

HTTP
Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; object-src 'none';

この例では、すべてのリソースを自身のサイト（’self’）に限定し、スクリプトに限ってのみ外部の「example.com」を許可しています。

また、object-src 'none';を指定することで、Flashなどのプラグインの読み込みを完全に禁止しています。

metaタグによる設定

サーバーの設定を変更できない環境では、HTMLの<head>セクション内に記述することで対応可能です。

ただし、frame-ancestorsなど一部のディレクティブはmetaタグでは機能しないため注意が必要です。

HTML
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

この設定により、画像のみあらゆるHTTPSサイトから読み込みを許可し、他の要素は自身のサイトのみに制限されます。

安全にCSPを導入するためのステップ

CSPは非常に強力な制限をかけるため、不適切な設定を行うと正常なコンテンツまで表示されなくなるリスクがあります。

既存のサイトに導入する場合は、段階を踏んで慎重に進めることが「運用の鍵」となります。

1. Report-Onlyモードの活用

いきなり制限を開始するのではなく、ポリシー違反をブラウザが検知した際に「報告だけ」を行う機能があります。

Content-Security-Policy-Report-Onlyヘッダーを使用することで、サイトの動作を停止させることなく、現在の設定でどこがブロックされるかを確認できます。

HTTP
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violation-report-endpoint/

このヘッダーを指定すると、違反が発生してもブラウザは実行を許可し続け、指定したエンドポイントにJSON形式のレポートを送信します。

管理者はこのレポートを分析することで、必要なドメインの許可漏れや、不要なスクリプトの存在を把握できます。

2. 違反レポートの分析と修正

収集されたレポートを基に、ポリシーを微調整していきます。

外部の広告配信スクリプトやアナリティクスツールなどは、予想外のドメインからリソースを読み込むことが多いため、それらを正確にホワイトリストに追加します。

このプロセスを数週間から数ヶ月繰り返すことで、安全かつ実用的なポリシーが完成します。

3. 強制（Enforce）モードへの移行

レポートが安定し、正常な動作が確認できたら、本来のContent-Security-Policyヘッダーに切り替えます。

これにより、定義されたポリシーに反する挙動はすべてブラウザによって遮断されるようになり、サイトの安全性が格段に向上します。

インラインスクリプトの扱いと「Nonce」の仕組み

CSP導入における最大の障壁の一つが、HTML内に直接記述されたJavaScript（インラインスクリプト）です。

本来はインラインスクリプトを排除し外部ファイル化するのが理想ですが、どうしても必要な場合があります。

その際、セキュリティを保ちつつ特定のインラインスクリプトのみを許可する方法としてNonce（ナンス）が利用されます。

Nonceは一度きりのランダムな文字列であり、これをサーバー側で生成してヘッダーとスクリプトタグの両方に含めます。

HTTP
Content-Security-Policy: script-src 'nonce-2726eb7ae06c'
HTML
<script nonce="2726eb7ae06c">
  console.log("このスクリプトは許可されます。");
</script>

ブラウザは、ヘッダーに記載されたNonceとスクリプトタグの属性値が一致する場合にのみ、そのスクリプトを実行します。

攻撃者はサーバーが生成した今回のNonceを知ることができないため、不正なスクリプトを注入しても実行させることはできません。

この手法は「Strict CSP」と呼ばれ、複雑なホワイトリスト管理を簡略化しつつ、極めて高いセキュリティを実現する推奨手法とされています。

CSP導入時の注意点と課題

CSPは万能な解決策ではなく、いくつかの注意点も存在します。

まず、サードパーティ製ライブラリへの依存が強いサイトでは、それらのスクリプトが読み込む「さらに先のソース」まで把握する必要があります。

許可リストが肥大化しすぎると、かえってセキュリティホールを見逃す原因にもなりかねません。

また、古いブラウザ（Internet Explorerなど）ではCSPの一部または全部がサポートされていないため、それらのユーザーに対しては別の防御策を維持する必要があります。

さらに、CSPの設定ミスはコンテンツの破損に直結するため、本番環境への適用前には徹底的なテストが不可欠です。

ポリシーが厳しすぎるとアクセシビリティや利便性が損なわれることもあるため、セキュリティと機能性のバランスを考慮した設計が求められます。

まとめ

コンテンツセキュリティポリシー（CSP）は、ウェブサイトをXSSやデータ注入攻撃から守るための非常に強力な防衛手段です。

ブラウザと連携してリソースの読み込みを制限することで、アプリケーションの安全性を根本から強化できます。

導入には初期の調査やテストが必要ですが、Report-Onlyモードを活用することで、サイトの稼働を止めることなく安全に設定を進めることが可能です。

まずはdefault-src 'self'を設定し、不要なリソースの読み込みを制限することから始めてみてはいかがでしょうか。

サイバー攻撃が巧妙化し続ける現代において、CSPの導入はユーザーの信頼を守るための重要なステップとなるはずです。