ドメイン番人
Web セキュリティCSPWeb 担当者学習

CSP（Content-Security-Policy）とは？Web 担当者のための入門

ドメイン番人約 5 分で読めます
目次

この記事でわかること

  • CSP（Content-Security-Policy）が「ブラウザに対する許可リスト」であること
  • CSP で防げる攻撃（XSS / 改ざん / 情報漏洩）と防げないもの
  • Web サイト運営者が最低限導入すべき CSP の例
  • 事故を出さずに導入する 3 段階のロールアウト

CSP は「ブラウザに対する許可リスト」

CSP（Content-Security-Policy）は、Web サイトのレスポンスヘッダで「このページが読み込んでよいリソースの出所」を宣言する仕組みです。スクリプト・スタイル・画像・iframe などのリソースが、許可されていない出所から来た場合にブラウザが読み込みをブロックします。

簡単な例:

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com

これは「自社ドメインからのリソースは全て OK、加えて Google Tag Manager の JS だけ許可」という宣言です。攻撃者が XSS で別ドメインの悪意あるスクリプトを注入しても、ブラウザがそれを実行する前に拒否します。

CSP の役割と効果範囲

CSP で防げる攻撃 / 防げない攻撃

防げる

  • XSS（クロスサイトスクリプティング）: 注入されたインラインスクリプトや外部スクリプトの実行を阻止
  • データ漏洩を狙う通信: connect-src で API 通信先を限定すれば、攻撃者が情報を別のサーバーに送ろうとしても止まる
  • 意図しないサードパーティタグ: 広告 SDK / 解析ツール等の出所制限
  • iframe による埋め込み攻撃: frame-ancestors / frame-src で制限可能

防げない

  • サーバー側の脆弱性: SQL インジェクション・認可バイパスなどはサーバーで対処
  • 人的ミス: フィッシングメールに誘導された結果のアカウント情報入力
  • DDoS / Brute Force: WAF / レート制限の領域

CSP は「クライアント側に到達したリソースを制御する」防御層です。サーバー側の対策と組み合わせて初めて意味が出ます。

最低限の CSP 例（小〜中規模サイト向け）

default-src 'self' を起点に、必要な外部ドメインだけ追加するのが安全です。

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com 'nonce-{{generated}}';
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'self';
  base-uri 'self';
  form-action 'self';

ポイント:

  • 'unsafe-inline' を script-src に入れない（XSS 防御効果が大きく下がる）。代わりに nonce または hash で個別許可
  • style-src の 'unsafe-inline' は WordPress 等のテーマで必要になりがち。許容するか、徐々に外すかは判断
  • frame-ancestors 'self' は X-Frame-Options の上位互換（クリックジャッキング対策）
  • base-uri / form-action を入れておくと攻撃面が更に狭まる

いきなり Enforce にしない（3 段階のロールアウト）

CSP の最大の落とし穴は「いきなり Enforce すると本番画面が崩壊する」ことです。サードパーティタグ・CDN・解析ツールが見えない場所で動いているため、ポリシー違反 = ブロック = 画面崩れになります。

CSP 導入の 3 段階

ステップ 1: Report-Only モードで観察

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

このヘッダはブラウザに「ポリシー違反を検出したら report-uri に通知して。でもブロックはしない」と指示します。実際の画面表示には影響しません。

report-uri の受け口は自前実装でも、Sentry / Datadog 等の監視サービスでも構いません。違反内容を 2〜4 週間蓄積します。

ステップ 2: ポリシー調整

レポートを精査して、

  • 「自社で使っている SDK だ」→ そのドメインを script-src に追加
  • 「見覚えのない出所」→ 攻撃の可能性 / 不要なタグの可能性を調査

を仕分けします。違反が 1 日数件以下に落ち着くまで観察を続けます。

ステップ 3: Enforce 切り替え

ヘッダ名を Content-Security-Policy-Report-Only から Content-Security-Policy に変更すれば本番適用です。違反したリソースは実際にブロックされ、XSS 防御が効きます。

CSP の unsafe-inline を巡る現実

WordPress や古いテーマでは、JavaScript / CSS がインラインで埋め込まれているケースが多く、'unsafe-inline' を入れないと画面が崩れます。一方 'unsafe-inline' を入れると CSP の XSS 防御効果は大きく下がります。

このトレードオフと現実的な移行手順は CSP unsafe-inline の問題と移行手順 で詳しく解説しています。

まずは現状を把握しましょう

自社サイトの CSP 設定状況は、ドメイン番人の Web セキュリティヘッダ 単発チェック で 30 秒で確認できます。CSP の有無、unsafe-inline の検出、Report-Only モードの判定までまとめてレポートします。

CSP の段階的な導入支援、CSP 違反レポートの精査、Enforce 切り替えのスポット対応は Web セキュリティヘッダ診断＋設定支援（3 万円〜）でご相談いただけます。判断に迷う場合は お問い合わせ からお気軽にどうぞ。

他社チェッカー（securityheaders.com / Mozilla Observatory）との違いは Web セキュリティヘッダのチェッカー比較 を、ブラウザ API（カメラ / マイク / 位置情報など）を制限する隣接ヘッダーは permissions-policy 設定の入門 を参照してください。

メール認証や SSL も含めた総合点検は 無料のドメイン診断 を、SSL 単独の確認は SSL 単発チェック をご利用ください。

関連記事

次の一歩は無料診断から。

無料診断を試す →相談したい方はこちらから