CSP 3 strict-dynamic（シーエスピースリーストリクトダイナミック）

概要

CSP 3 strict-dynamicは2024年に主要ブラウザでフル対応(Baseline)した、Content Security Policy(CSP) Level 3の重要ディレクティブで、XSS(Cross-Site Scripting)攻撃防御をより堅牢にしつつ、レガシーホストリストの制約を緩和した次世代CSP戦略の中核。従来CSP 2のホストリスト方式(script-src 'self' https://example.com)では、信頼ホストにXSSが入ると攻撃連鎖を防げない問題があったが、strict-dynamicはNonce(乱数)・Hashベースのスクリプト信頼チェーンを構築し、Nonceで信頼されたスクリプトから動的に挿入された子スクリプトも自動的に信頼する仕組み。Chrome 52+(2016年)・Firefox 49+(2016年)・Safari 15.4+(2022年)で対応し、2024年にBaseline Newly available到達。Google・Cloudflare・Shopify等の大手Webサービスが本格採用し、業界標準の堅牢CSP戦略として定着。

主な特徴・仕組み

• Nonce-based信頼: <script nonce="rAndOm123"> のNonceでスクリプトを信頼
• strict-dynamicディレクティブ: 信頼されたスクリプトから生成された子スクリプトも信頼
• ホストリスト無効化: strict-dynamicがあるとhttps://example.com等のホストは無視
• Hash-based信頼: 静的スクリプトはSHA256/384/512ハッシュで信頼可能
• 'unsafe-inline' Backward Compat: 古いブラウザではunsafe-inlineで動作
• 'unsafe-hashes': インラインevent handlerをHash信頼可能(CSP Level 3新規)
• CSP Reporting Endpoint: Content-Security-Policy-Report-Only+ report-uri で違反通知
• 'wasm-unsafe-eval': WebAssembly実行許可、CSP 3新ディレクティブ
• Trusted Types統合: W3C Trusted Types APIと組合せでDOM XSS完全防御
• CSP Inheritance: iframe親→子CSP伝播、適切なFrame制御
• Browser Support: Chrome 52+/Firefox 49+/Safari 15.4+/Edge 79+ Baseline 2024

スペック比較表

具体例・対応製品

Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-r4nd0m123' 'strict-dynamic' 'unsafe-inline' https:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'self';
  report-uri /csp-report;

<!-- Nonce-based信頼スクリプト -->
&lt;script nonce="r4nd0m123">
  console.log('信頼されたインラインスクリプト');
&lt;/script>

<!-- 動的に挿入されたスクリプトも自動信頼 -->
&lt;script nonce="r4nd0m123">
  const script = document.createElement('script');
  script.src = 'https://untrusted-cdn.example.com/lib.js';
  document.head.appendChild(script);  // strict-dynamicでホストリスト無視+信頼
&lt;/script>

• Google Search/Gmail: CSP 3 strict-dynamic本格採用、業界トップ事例
• Cloudflare Workers: CSP 3対応、Edge Worker XSS防御
• Shopify Storefront: 数百万のEC StoreでCSP 3 strict-dynamic適用
• GitHub: 2023年から段階移行、CSP違反監視+Report-Only運用
• 競合機種: CSP 2 host-list方式(レガシー)、Web Application Firewall(WAF)、DOMPurify(JavaScript Sanitizer)

自作PCでの選び方・注意点

CSP 3 strict-dynamicはWeb開発者向けのセキュリティ仕様で、jisaku.comのWeb Frontend(Next.js 16+TypeScript)では運用必須レベルの重要技術。Next.js 16はCSP 3対応のnext.config.js headers設定で容易に実装可能。Nonce-based信頼を採用する場合、SSR(Server-side Rendering)で動的にNonce生成+各リクエストで一意の値をHTTP HeaderとHTMLに注入する必要があり、Next.js Middleware(middleware.ts)経由でcrypto.randomUUID()で実装が一般的。一方、Static Generation(SSG)+CDN配信構成ではNonce動的化が困難なため、Hash信頼+'unsafe-inline' Fallbackの組合せが現実的。jisaku.comでは現在CSP 2 host-list方式運用中だが、CSP 3 strict-dynamic移行で外部CDN(Vercel/Cloudflare R2)経由のスクリプト読込も柔軟になり、信頼できないスクリプト挿入(advertise/malicious 3rd-party)防御も強化される。Report-Only モード(Content-Security-Policy-Report-Only)を1-2週間運用してから本適用するのが安全な移行Path。Sentry/Datadog等のRUM(Real User Monitoring)ツールはCSP違反でブロックされる恐れがあるため、Nonceまたはホスト例外設定が必要。

関連用語との違い

CSP 2 host-list方式との違い: CSP 2は信頼ホストリスト(script-src https://example.com)、CSP 3 strict-dynamicはNonce/Hash信頼+strict-dynamicでスクリプトチェーン信頼。CSP 2は信頼ホストにXSSが入ると連鎖、CSP 3はNonceのみ信頼でXSS連鎖防御。 Trusted Typesとの違い: strict-dynamicはreflected/stored XSS防御、Trusted TypesはDOM-based XSS(element.innerHTML = userInput等)防御。両者組合せで完全な多層XSS防御となる。両方をCSP仕様で統合管理可能。

よくある質問（FAQ）

Q1: 既存サイトでCSP 3 strict-dynamic移行する手順は？ A: 1) Report-Only モードで2-4週間違反監視、2) 全インラインスクリプトをNonce/Hashに変換、3) CSP 3+strict-dynamic で本適用、4) 1か月以上違反監視継続、5) ホストリスト除去で完了。Google/Shopify事例で6か月かけて段階移行。

Q2: Next.js/Astro/Remix等のSSRでNonce実装方法は？ A: SSR Middlewareで毎リクエストNonce生成+Content-Security-Policy Headerと<script nonce>で同一値設定。Next.js 16ならmiddleware.ts、Astro 5はAstro.locals.cspNonce、Remix 2はheaders() Loader Functionで実装。

Q3: CSP違反レポートはどう監視する？ A: report-uri /csp-reportまたは report-toで違反通知Endpointを設定、Sentry CSP integration/Cloudflare CSP Reports/独自エンドポイントで集計。違反パターン(allowed src外+attempted+host)から攻撃検知や設定漏れ発見可能。

まとめ

• CSP 3 strict-dynamic = 2024年Baseline Newly available
• Nonce/Hash信頼+strict-dynamicでスクリプトチェーン自動信頼
• ホストリスト方式(CSP 2)からの移行で XSS防御大幅強化
• Google/Cloudflare/Shopify業界標準採用
• Trusted Types統合で完全な多層XSS防御実現