コンテンツセキュリティ入門：CSPと関連対策を深掘りし、WordPressで安全に運用する方法
エバープレイ編集部はじめに：コンテンツセキュリティとは何か
「コンテンツセキュリティ」は、ウェブアプリケーションやウェブサイト上で配信されるコンテンツ（HTML、JavaScript、CSS、画像、フォント、メディア等）が意図しない実行や読み込み、改ざんを受けないように制御する考え方と技術の総称です。特に注目されるのが Content Security Policy（CSP）で、ブラウザ側で許可されるコンテンツの出所や実行方法を宣言的に制御します。その他、HTTPヘッダやCookie属性（HttpOnly、Secure、SameSite）なども含め、総合的に検討する必要があります。
CSP（Content Security Policy）の基本概念
CSPは、サーバーがレスポンスヘッダ（またはmetaタグ）でポリシーを指定し、ブラウザがそのポリシーに従ってリソースの読み込みやスクリプト実行を制限する仕組みです。主な目的はクロスサイトスクリプティング（XSS）攻撃やデータインジェクションの影響を低減することです。
- ポリシーはディレクティブ（例: default-src, script-src, style-src, img-src, connect-src, frame-ancestors 等）で構成される。
- 特定のオリジン（https://example.com）やキーワード（'self'、'unsafe-inline'、'unsafe-eval'）、nonceやハッシュ（'nonce-...'、'sha256-...'）で許可を細かく設定できる。
- report-uri（古い）、report-to（新しい）を使って違反を収集できる（監査やチューニングに有用）。
主なディレクティブと使いどころ
- default-src: 他のディレクティブが未指定のときのデフォルトポリシー。
- script-src / style-src: 外部スクリプト・スタイルの読み込みとインライン実行の許可。インライン実行は'unsafe-inline'を避け、nonceまたはハッシュを推奨。
- img-src / font-src / media-src: 画像、フォント、音声/動画の読み込み元を制限。
- connect-src: fetch/XHR/WebSocket等の接続先を制限。
- frame-ancestors: ページがどこからiframeに埋め込まれるかを制御（X-Frame-Options の近代的代替）。
- object-src:
- base-uri / form-action: ベースURIやフォーム送信先の制限。
nonce とハッシュの使い分け
インラインスクリプトを安全に許可する方法として、nonce（ワンタイムトークン）とハッシュがあります。nonceはレスポンス毎に生成してスクリプトタグに付与し、ヘッダでそのnonceを許可します。ハッシュは固定のインラインスクリプト内容に対して使えます。
- nonce: サーバー側でランダムに生成し、レスポンスのヘッダと対応するスクリプトタグに同じ値を付与する。WordPressなど動的サイトで便利。再利用を避けるため短時間で無効化する運用が必要。
- ハッシュ: スクリプト内容が変わらない場合に有効。CDNなどで静的に配信するスニペットに向く。
その他の有効なHTTPヘッダ
- X-Content-Type-Options: nosniff — MIMEスニッフィングを防ぎ、ブラウザがレスポンスのContent-Typeを厳密に扱うよう指示する。
- X-Frame-Options — 古いブラウザ向けにiframe埋め込みを制御（DENY / SAMEORIGIN）。ただし現代的には frame-ancestors を使うべき。
- Referrer-Policy — リファラ情報の送信範囲を制御。プライバシー観点で重要（例: no-referrer, strict-origin-when-cross-origin）。
- Permissions-Policy（旧 Feature-Policy） — カメラ/マイク等の機能利用を制限。
- Strict-Transport-Security (HSTS) — HTTPSのみを強制する。max-age、includeSubDomains、preload 指定を適切に設定する。
WordPress特有の注意点と導入手順
WordPressはテーマやプラグイン、ウィジェットが動的にHTML/JS/CSSを生成するため、CSP導入が難しいことが多いです。主な課題はインラインスクリプトや外部CDN、管理画面での動作です。推奨する導入フローは次の通りです。
- ステージング環境でまずは report-only モードでCSPを有効にし、ブラウザコンソールやレポートから必要なホストやスクリプトを洗い出す。
- インラインスクリプトが多い場合は nonce を採用する。PHPで nonce を生成し、wp_head や wp_footer 等でスクリプトタグに埋め込む。例: $nonce = base64_encode(random_bytes(18)); header("Content-Security-Policy: script-src 'self' 'nonce-$nonce';"); ただし WordPress の出力バッファリングとヘッダ送信タイミングに注意する。
- プラグインやテーマの外部リソース（Google Fonts, Analytics, CDN等）はホワイトリスト化する。可能ならSRI（Subresource Integrity）を併用して外部スクリプトの改ざんを検出・防止する。
- 管理画面（/wp-admin）やREST API、Ajaxエンドポイント毎に異なるポリシーが必要な場合がある。エリアごとにヘッダを切り替える実装を検討する。
- テストを十分に行い、徐々に厳格化する。開発者や非技術ユーザーの混乱を避けるため、ドキュメントを整備する。
運用上のベストプラクティス
- まず report-only で運用し、レポート内容を精査してからエンフォースに移行する。
- 可能な限り 'unsafe-inline' と 'unsafe-eval' を使わない。既存コードをリファクタリングして外部スクリプトやモジュール化を進める。
- Cookie には HttpOnly、Secure、SameSite 属性を設定する（SameSite=Lax 以上を推奨）。
- SRI を利用できる外部リソースには必ず導入する。SRI は静的ファイルに有効だが、動的に変わるファイルには適さない点に注意。
- 定期的にブラウザ互換性とセキュリティヘッダのチェックを自動化する（例: Mozilla Observatory、securityheaders.com 等）。
よくある落とし穴と回避策
- インラインイベントハンドラ（onclick 等）を多用していると nonce 方式でも対応が難しい。イベントリスナを外部スクリプトに移行する。
- サードパーティライブラリやプラグインが動作しなくなるケース。事前に依存関係を洗い出し、必要なら代替ライブラリやホスティング方法を検討する。
- ポリシーが過度に緩い（'unsafe-inline' を多用）とCSPの効果が薄れる。段階的に改善していく。
- レポートが大量に届いて解析が追いつかない場合は、集約ツールやログ解析を用いる。report-to でグループ化し、専用のエンドポイントで処理するのが有用。
実践的なCSPヘッダ例（逐次改善のための出発点）
以下は基本的な例。運用・要件に応じてホストやディレクティブを調整してください。
report-only フェーズ例（初期診断用）:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.example.com; report-to csp-endpoint;
enforce フェーズ例（nonce を利用）:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-
テストと監視のツール
- ブラウザ開発者ツール — CSP違反はコンソールやNetworkのレスポンスヘッダで確認できる。
- report-uri / report-to エンドポイントで自動的に違反を集める。ログを可視化することで漏れを見つけやすくなる。
- Mozilla Observatory、securityheaders.com、CSP Evaluator（Google）などで設定の評価や脆弱性の発見に役立つ。
まとめ：段階的な導入で実効性を高める
コンテンツセキュリティは一度設定して終わりではなく、継続的に監視・改善していくプロセスです。まずはreport-onlyで現状を把握し、nonceやハッシュ、SRI、適切なHTTPヘッダと組み合わせることで、XSS等のリスクを大幅に低減できます。WordPress環境ではプラグインやテーマごとの調整が必要になるため、段階的に導入していく運用が現実的です。最終的にはユーザー体験を損なわずにセキュリティ強度を高めるバランスを目指してください。
参考文献
- MDN Web Docs: Content Security Policy (CSP)
- W3C: Content Security Policy (CSP) Specification
- MDN: X-Content-Type-Options
- MDN: Referrer-Policy
- MDN: Strict-Transport-Security
- OWASP: Content Security Policy for XSS Prevention
- SecurityHeaders.com
投稿者プロフィール
最新の投稿
用語2025.12.14ベースライン完全ガイド：役割・歴史・制作テクニックと名例で学ぶ深掘り解説- 用語2025.12.14グライム（Grime）完全ガイド：起源・サウンド・文化・現代への影響を徹底解説
- 用語2025.12.14UKガラージュ（UK Garage）徹底解説：起源・音楽性・進化と現代への影響
- 用語2025.12.14Trapstep徹底解説：起源・音楽的特徴・制作テクニックとその進化
