Webサイトのセキュリティ対策として耳にすることが多いCSPとは何か、設定の基本はどうなっているのか、具体的にどんなディレクティブ（指令）があり、どう適用すればいいかを初心者にも分かりやすく解説します。CSPを正しく設定すればクロスサイトスクリプティング（XSS）やクリックジャッキング等の攻撃を効果的に防ぐことができるため、最新情報にもとづいた設定方法を身につけましょう。
目次
CSP とは 設定 基本
Webサイトのセキュリティに関心がある人が「CSP とは 設定 基本」というキーワードで検索する意図のひとつは、CSPの定義・導入意義・構成要素を理解したいということです。CSP（Content Security Policy）がどのようなものか、どんな脅威を防ぐか、基本的な書き方や構文を学びたいというニーズがあります。また、設定時の注意点や各ディレクティブの意味、例も知りたいはずです。さらに、自分のサイトにどう適用すべきか、設定ミスで起こる影響も気になるポイントです。
CSPの定義と役割
CSPはコンテンツセキュリティポリシーの略で、Webサイトがブラウザーに対してどのような種類の外部リソースを読み込んでよいかを指示する仕組みです。特にスクリプト・スタイル・画像などのリソースの出所を限定することで、不正なスクリプトの挿入やサイトの改ざんといった攻撃を防ぐことができます。ブラウザはこれらの指令に従い、許可されていないソースからのリソース読み込みを拒否します。これはXSS防止・クリックジャッキング防止などに効果があります。
CSPを導入するメリット
CSPを適切に設定することには複数の利点があります。まず第一に、クロスサイトスクリプティングのリスクを大幅に低減できる点です。次に、クリックジャッキングなどのUIを偽装する攻撃を防止できます。さらに、不正な外部リソースの読み込み制限により情報漏洩リスクを抑えられ、HTTPS化の強制なども可能になります。これらはユーザーとサイト運営者双方にとって信頼性を高める要素となります。
CSPの構文と基本設定方法
CSPは通常、HTTPレスポンスヘッダー「Content-Security-Policy」またはHTMLヘッダー内のタグで指定します。ポリシーは複数のディレクティブで構成され、各ディレクティブには種類と値があり、セミコロンで区切ります。例として「default-src ‘self’」は基本ソースを自サイトのオリジンのみにする指令です。構文の基本を理解することで、安全かつ機能を保ったCSP設定が可能になります。
CSPの主要ディレクティブとその使い方
CSPの設定で最も重要なのは、どのディレクティブを含めて、どの値を設定するかを把握することです。ここでは代表的なディレクティブを解説し、それぞれの目的や設定時のポイント、一般的な値（’self’／’none’／unsafe-inline／nonce／hashなど）について説明します。初心者でも混乱しやすい値の使い分けも含めて理解を深めましょう。
default-srcディレクティブ
default-srcはCSPの「土台」であり、他の -src系ディレクティブ（script-src, img-srcなど）で明示しない限り、読み込みを許可するデフォルトのオリジンを指定します。通常は自身のドメイン（’self’）を指定し、可能な限り外部の場所は避け、信頼できるCDN等のみを明示的に許可すると安全です。「none」を使うと完全に拒否するモードになります。
script-src, style-srcなどリソース系ディレクティブ
script-srcはJavaScript、style-srcはCSS／スタイルを読み込むソースを制御します。インラインスクリプトやunsafe-evalの許可はセキュリティリスクを高めるため、nonceやハッシュを使って限定的に許可するのが推奨されます。スタイルに関しても同様に、インラインスタイルを避け、外部スタイルシートを利用する方が望ましいです。
img-src, font-src, media-srcなど静的リソースと外部API制限
img-srcは画像を読み込めるドメインを制限し、「data:」形式の使用を必要に応じて許可します。font-srcはフォントファイルの取得先、media-srcは動画・音声を許可するソースを指定します。connect-srcはフェッチやAPI通信、WebSocket等を制御します。これらを明示することにより、悪意のある外部リソースの読み込みを未然に防げます。
frame-ancestors, frame-src, object-srcなど埋め込み制御用ディレクティブ
frame-ancestorsはページをどのサイトに埋め込ませるかを制限し、クリックジャッキング防止に有効です。frame-srcはiframeなどの埋め込みコンテンツの読み込み先を制限します。object-srcはFlashやプラグイン等過去の非推奨技術の読み込みを抑制する目的で使用され、通常は ‘none’ が安全な設定です。
CSPの設定時の実践ポイントと注意点
CSPを導入する際はいくつか注意すべき点があります。設定過剰でサイトが壊れることや、パフォーマンス低下、メンテナンスコストの増加などの副作用です。ここではそうしたリスクを抑えつつ、安全で実用的な設定を行うステップや、テストモード利用・レポート収集の方法など実践的アプローチを紹介します。
report-onlyモードでテストを行う
まずは本番環境に適用する前に、report-onlyモードを使ってポリシーをテストすることが重要です。このモードではブラウザはポリシー違反を報告するだけで読み込み制限はしないため、どのリソースがブロックされるかを事前に把握できます。これにより、必要なドメインを漏れなく許可し、サイト表示の問題を防げます。
nonceとハッシュの利用でインラインスクリプトを安全に制限
インラインスクリプトを完全に禁止すると利便性が落ちる場合があります。そのような時はnonceまたはハッシュを活用して、特定のスクリプトのみを許可する設定が可能です。nonceはリクエストごとに変わる一時的なトークンであり、ハッシュは内容の変更を検出する方式です。これらを使うことで、外部コードや改ざんされたスクリプトの実行を防げます。
unsafe-inlineやunsafe-evalの使用を最小限にする
unsafe-inlineとunsafe-evalは強力だが危険な値です。これらを使用すると、XSS攻撃の媒介になる可能性が高まります。原則としてこれらは避け、どうしても必要な機能に対してのみ限定的に用いるべきです。それに代わる方法としてnonceやハッシュの使用が推奨されます。
サブリソースインテグリティ（SRI）やHTTPS強制との併用
SRI（Subresource Integrity）は外部スクリプトやスタイルが改ざんされていないかを検証する技術です。CSPと組み合わせることでさらに強固なセキュリティが確保できます。加えて upgrade-insecure-requests を使ってHTTPアクセスをHTTPSに書き換える設定も有効です。これにより混在コンテンツの脆弱性を防げます。
CSPをWordPressで導入する手順
WordPressでCSPを導入するには、テーマまたはプラグイン、ウェブサーバ設定など複数の方法があります。管理画面でパーミッションやキャッシュの問題にも注意しながら、安全で整った設定を行います。ここでは具体的なステップを順を追って解説しますので、初心者でもスムーズに導入できます。
HTTPヘッダーでCSPを設定する方法
WebサーバやレンタルサーバでCSPを有効にするには、応答ヘッダーを設定するのが基本です。Apacheでは .htaccess やサーバ設定ファイルに「Header set Content-Security-Policy …」のように記載し、nginxでは response_header で設定します。これにより全てのページで同様のポリシーを適用でき、metaタグだけではカバーしきれないリスクを防げます。
テーマやプラグインでのCSP設定支援ツール
WordPressにはCSP設定を簡単に補助するプラグインが存在します。これらは必要なディレクティブをGUIで追加できたり、nonce自動生成機能を持つものがあります。ただしプラグインを選ぶ際は更新頻度・互換性・設定の柔軟性を確認し、サイト表示が崩れないようにテストしながら導入することが大切です。
よく起こる誤りとトラブル対処方法
CSP導入時によく起きるミスとしては、必要な外部ドメインを許可していないためスクリプトやフォントが読み込めない、インラインイベントハンドラが動作しない、キャッシュに古いポリシーが残っているなどがあります。こうした問題はブラウザの開発ツールでエラーを確認し、漏れているソースを段階的に追加して調整することで解消できます。
CSPの例と比較：簡単なポリシーから厳格モードまで
実際にどのようなCSPを設定できるか、用途別に例を比較すると理解が深まります。軽めのサイトや小規模ブログ向け、リスクが高いアプリケーション向けにそれぞれのポリシー例を示し、どこまで緩めるか厳しくするかの判断基準を探ります。
基本的なポリシー例（緩め）
たとえばブログや情報サイトなど、外部スクリプトが少ないサイトでは、以下のようなポリシーが適用できます。
default-src ‘self’;
script-src ‘self’ https://trusted-cdn.example; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’ data:; connect-src ‘self’;
このように必要最小限の外部ソースを許可しながら、サイトの機能を損なわない範囲で設定を整えることが可能です。
標準的なポリシー例（バランス型）
中規模のWebアプリでは、次のような設定がよく用いられます。
default-src ‘self’;
script-src ‘self’ https://trusted-cdn.example ‘nonce-{ランダム値}’;
style-src ‘self’ https://trusted-styles.example; img-src ‘self’ https://images.example data:; connect-src ‘self’ https://api.example; frame-ancestors ‘self’; object-src ‘none’;
この構成だとインラインスクリプトを制限し、外部ドメインは信頼できるもののみに絞り、クリックジャッキング対策も含みます。
厳格なポリシー例（セキュリティ重視型）
ミッションクリティカルなサイトや外部の攻撃リスクが高いサイトでは、さらに厳格な設定が適切です。
default-src ‘self’;
script-src ‘nonce-{ランダム値}’;
style-src ‘nonce-{ランダム値}’;
img-src ‘self’; connect-src ‘self’; frame-ancestors ‘none’; object-src ‘none’; base-uri ‘none’;
このように外部ソースをほぼ完全に遮断し、非同期通信も最小限とし、可能な限り安全性を追求します。ただし利便性や機能が制限されることを理解し、広範なテストが必要です。
まとめ
CSPとは、Webサイトが読み込む外部リソースの出所を制限し、XSSやクリックジャッキングなどの攻撃から守るための重要なセキュリティ機構です。デフォルトのディレクティブや script-src、img-src、frame-ancestors などを理解することで、どのような設定が自分のサイトに適切か判断できるようになります。
設定時には report-only モードでテストし、nonce／ハッシュを活用し、unsafe-inline や unsafe-eval の使用をなるべく避けることがポイントです。またサブリソースインテグリティや HTTPS 強制との併用でセキュリティをさらに強化できます。
WordPress の導入では、応答ヘッダーでの設定、プラグインの利用、テーマ調整など複数の手法がありますが、テストと段階的な適用が失敗を避ける鍵です。自分のサイトに合ったバランスで、最新の情報を取り入れつつ安全な CSP 設定を心がけてください。
コメント