CSP（Content Security Policy）はブラウザに対してページ上で実行・読み込みを許可するリソースの種類とオリジンを宣言するセキュリティ機構で、2014年2月にW3Cがレベル1のRecommendationを公開し、2016年にレベル2、2018年からはレベル3がCRとして整備されてきた。XSSやデータ注入、クリックジャッキングといった攻撃を多層的に抑止する目的で導入され、現在はHTTPヘッダContent-Security-PolicyやHTMLのmetaタグを通じて配信される。本稿では制定経緯、ディレクティブ構造、nonce／hashを使う運用、CSPと併用する補助機構を整理する。
この記事の目次
- CSPが必要とされた背景と歴史
- 主要ディレクティブとフォールバック
- nonceとhashで実現するインラインスクリプト制御
- 他の防御機構との関係
- まとめ
CSPが必要とされた背景と歴史
2007年頃からMozillaの研究者Brandon Sterneらが「Content Restrictions」という名でブラウザ側のホワイトリスト機構を提案し、Firefox 4で実験的にX-Content-Security-Policyヘッダが実装された。これを土台にW3CのWebAppSec Working Groupが2011年から標準化を始め、2014年2月19日にレベル1がRecommendationとなった。レベル2では2016年にhash-source・nonce-sourceなどが追加され、レベル3では2018年からCandidate Recommendationとしてstrict-dynamicやTrusted Typesとの統合が進められている。
CSPの設計思想は「明示的に許可したものだけを実行する」というホワイトリスト方式である。従来のサニタイズや入力フィルタが攻撃者の創意工夫に追従し切れない現実を踏まえ、最後の防衛線としてリソースの取得元自体を制限する。Googleの社内分析では、CSPを適切に運用したサービスでXSSの実害をほぼ封じ込められたという報告があり、現代の主要Webサービスはほぼ例外なくCSPを設定している。
主要ディレクティブとフォールバック
CSPはディレクティブ単位で取得元を指定する。default-srcはフォールバック、script-src、style-src、img-src、connect-src、font-src、frame-src、media-src、worker-srcなどが個別リソースの種類を制御する。script-srcやstyle-srcに'self'、'unsafe-inline'、'unsafe-eval'、ホスト名、'nonce-xxxx'、'sha256-…'などを並べて記述する。フレーム埋め込みを制限するframe-ancestorsはX-Frame-Optionsの後継で、クリックジャッキング対策として重要である。
報告系ディレクティブにはreport-uri（旧式）、report-to（Reporting API連携）、Content-Security-Policy-Report-Only（検査専用モード）がある。本番投入前にReport-Onlyで違反データを集めながらポリシーを煮詰める運用が一般的で、ChromeのDevToolsやFirefoxのコンソールに違反理由が表示されるため、開発時のチューニングも比較的容易である。プリロード対象のscriptをCDNから配信する場合は、CDNドメインの追加とSubresource Integrity（SRI）の併用が推奨される。
nonceとhashで実現するインラインスクリプト制御
従来CSPと相性が悪かったインラインスクリプトを安全に許可する手段が、nonceとhashである。nonce方式ではリクエスト毎にサーバが一意の乱数を生成し、HTMLの