コンテンツセキュリティポリシー (CSP).

CSP はレスポンスヘッダ Content-Security-Policy(または meta 要素)で配信され、script-src・style-src・img-src・connect-src・frame-ancestors などリソース種別ごとに細かな許可リストを適用します。W3C によって標準化されており、CSP Level 3 で厳格なポリシーを実用的にするための各種プリミティブが導入されました。多層防御の一手段として、XSS・クリックジャッキング(frame-ancestors による)・混在コンテンツの影響を大幅に軽減しますが、入力検証や出力エンコードの代替にはなりません。

ホスト許可リストは典型的な失敗です。 Google の研究(約 10 億ページを分析した論文 CSP Is Dead, Long Live CSP!)によれば、ホストベースのポリシーの大半は簡単に回避できました。多くの場合、許可した CDN が JSONP エンドポイントも配信していたり、gadget として悪用できる古い Angular/AngularJS ビルドをホストしていたためです。現代的な答えは nonce ベースの厳格な CSP です。レスポンスごとに新しいランダムな nonce を発行し(script-src 'nonce-r4nd0m')、インラインスクリプトはその nonce を持ち、nonce を持たない注入された <script> はそもそも実行されません。nonce を 'strict-dynamic' と組み合わせると、信頼されたスクリプトが自身の依存を読み込みつつホスト許可リストを完全に無視できるため、ポリシーを短く保ち CDN 非依存にできます。<object> と <base> タグによる回避を塞ぐため、必ず object-src 'none' と base-uri 'none' を追加してください。

Content-Security-Policy-Report-Only を使えば安全に展開できます。これは何も強制しませんが、report-to/report-uri を通じて JSON の違反レポートを送信するため、強制モードへ切り替える前に実トラフィックに対してポリシーを調整できます。GitHub・Google・Dropbox はいずれも本番環境で nonce ベースの厳格な CSP を運用しています。ヘッダはクライアント側でブラウザにより強制されるため、サーバ側の注入を防止するのではなく緩和するものである点に留意してください。

flowchart TD
  A[サーバがレスポンスを生成] --> B[リクエストごとに新しいランダム nonce]
  B --> C["Header: script-src 'nonce-abc123' 'strict-dynamic'; object-src 'none'; base-uri 'none'"]
  C --> D[ブラウザがページを解析]
  D --> E{スクリプトは一致する nonce を持つか?}
  E -->|はい:正当なインラインスクリプト| F[実行 + strict-dynamic が依存を読み込む]
  E -->|いいえ:XSS で注入されたスクリプトタグ| G[ブロック]
  G --> H[report-to エンドポイントへ違反レポート]
  style F fill:#27ae60,color:#fff
  style G fill:#c0392b,color:#fff