2025/7/24 日本経済新聞社　CDIO室 飯沼翼 CSPヘッダー導入で実現するWebサイトの多層防御 ― 今すぐ試せる設定例と運用知見 ― NIKKEI TECH TALK #35 

ハッシュタグ #nikkei_tech_talk 自己紹介 2 飯沼 翼 (Tsubasa Iinuma) ● 所属： 株式会社日本経済新聞社 CDIO室 セキュリティチーム セキュリティエンジニア ● 普段の業務： プロダクトセキュリティの専任者として、 主にアプリケーションセキュリティ領域を担当 ● 好きなこと： セキュリティについて語り合いながらお酒を飲む🍷 

ハッシュタグ #nikkei_tech_talk ● Content Security Policy (CSP)の概要 ● 多層防御の必要性とCSPの位置付け ● CSP導入の段階的アプローチ ● CSP導入の3ステップ紹介 ● Tips: CSPバイパス ● まとめ きょうの流れ 3 

ハッシュタグ #nikkei_tech_talk ● Webサイトがブラウザに対し、読み込みを許可するリソースを伝え るためのHTTPヘッダー ● 主なディレクティブ ○ script-src: JavaScriptの読み込みと実行を保護 ○ style-src: CSSの読み込みと実行を保護 ○ img-src: 画像の読み込みを保護 ● 仕様のバージョンは「Level」で表され、現時点の最新はLevel 3 ● クロスサイト・スクリプティング（XSS）攻撃のリスクを軽減 Content Security Policy (CSP)の概要 4 

ハッシュタグ #nikkei_tech_talk ● Webサイトに悪意のあるスクリプトを埋め込まれる脆弱性 ● 悪用された場合、Webサイトの改ざん、個人情報の漏えい、 Cookie情報の窃取などの被害に遭うおそれ ○ 近年では、マルウェア配布サイトへの誘導手段としても利用 ● 2025年現在でも、最も発見されている脆弱性の1つ クロスサイト・スクリプティング（XSS）とは 5 

ハッシュタグ #nikkei_tech_talk なぜ多層防御が必要か？ ● 対策は破られる可能性がある ● 単一の防御だけでは、未知の脆弱性や実装ミスで突破されるリス クが残る ● 近年のVibe Codingの普及により、脆弱性のあるコードが混入し やすくなっている 多層防御の必要性とCSPの位置付け 6 

ハッシュタグ #nikkei_tech_talk Webセキュリティにおける多層防御のイメージ ● 第1層: WAF ○ アプリケーションの手前で不正なリクエストをブロック ● 第2層: 入口対策（バリデーション） ○ 不正なデータを受け付けない ● 第3層: 出口対策（エスケープ処理） ○ データの出力や処理時にコンテキストに応じたエスケープ 多層防御の必要性とCSPの位置付け 7 

ハッシュタグ #nikkei_tech_talk Webセキュリティにおける多層防御のイメージ ● 第1層: WAF ○ アプリケーションの手前で不正なリクエストをブロック ● 第2層: 入口対策（バリデーション） ○ 不正なデータを受け付けない ● 第3層: 出口対策（エスケープ処理） ○ データの出力や処理時にコンテキストに応じたエスケープ →これらの対策をすり抜けられたら…？ 多層防御の必要性とCSPの位置付け 8 

ハッシュタグ #nikkei_tech_talk CSPの位置付け ● クロスサイト・スクリプティング（XSS）への最後の砦 ● ユーザーのブラウザ上で不正なスクリプトの実行を阻止 ○ 被害を水際で防ぐことができる ● 今回はCSP Level 3を使った例を紹介 多層防御の必要性とCSPの位置付け 9 

ハッシュタグ #nikkei_tech_talk CSP導入の段階的アプローチ 10 現状把握とポリシー設計 ポリシー 案の決定 現状分析と ポリシー案の策定 レポート収集とポリシー改善 Report-Only モードで導入 違反レポートの 収集と分析 ポリシーの修正 ポリシーに 見落としや 不備は？ 本番適用と継続的監視 Enforceモードで 導入 継続的な監視と メンテナンス いいえ はい 

ハッシュタグ #nikkei_tech_talk CSP導入の段階的アプローチ 11 現状把握とポリシー設計 ポリシー 案の決定 現状分析と ポリシー案の策定 レポート収集とポリシー改善 Report-Only モードで導入 違反レポートの 収集と分析 ポリシーの修正 ポリシーに 見落としや 不備は？ 本番適用と継続的監視 Enforceモードで 導入 継続的な監視と メンテナンス いいえ はい Step 1 Step 2 Step 3 

ハッシュタグ #nikkei_tech_talk ● 事前にチームごとの役割分担をしておくと進めやすい （日経の場合） ● 開発チーム： ○ 対象範囲決定、ポリシー策定、メンテナンスなど ● セキュリティチーム： ○ 質疑応答（技術支援）、ポリシーレビュー Step 0: 事前準備 12 

ハッシュタグ #nikkei_tech_talk 1. 現状分析 ● 導入予定のプロダクトのリソース使用状況を把握する ○ インラインスクリプトが多い、公開CDNを利用しているなど ● ブラウザの開発者ツールなどを用いて、サイトで読み込まれている リソースのドメインを収集 ○ 厳しいポリシー（default-src: 'none'）をReport-Onlyモー ドで導入し、レポートを収集して洗い出すのも効率的 ○ report-toディレクティブを使用すると、Reporting API経 由で送信されるので開発者ツールで確認しやすい Step 1: 現状把握とポリシー設計 13 

ハッシュタグ #nikkei_tech_talk 2. ポリシー方針の決定 Step 1: 現状把握とポリシー設計 14 方式 推奨度 メリット デメリット おすすめ Strict CSP (nonce/hash) ★★★ 最も安全 導入コストが高い 新規プロダクト 許可リスト ★★☆ バランスが良い バイパスリスクあり （後ほど説明） 新規プロダクト 既存プロダクト unsafe-inline ★☆☆ 導入が一番楽 XSS対策効果が激減 非推奨 （最終手段） 

ハッシュタグ #nikkei_tech_talk 3. ポリシー案の策定 ● 許可リストを選んだ場合： ○ 洗い出したドメインをscript-srcなどに設定 ● Strict CSPを選んだ場合： ○ サーバーサイドでリクエストごとにユニークな文字列（nonce） を生成し、CSPヘッダーとHTML内の要素のnonce属性にそ れぞれ設定 ○ どこでnonceを生成するかなども併せて決定 Step 1: 現状把握とポリシー設計 15 

ハッシュタグ #nikkei_tech_talk 1. Report-Onlyモードで導入 ● 読み込みや実行は制限はされないので、本番環境でも利用可 ● 違反があった場合にはレポートだけを送信 Step 2: レポート収集とポリシー改善 16 Content-Security-Policy-Report-Only: ; …; ; report-uri 

ハッシュタグ #nikkei_tech_talk 2. レポートの送信先 ● SentryやDatadogなどのエラー監視SaaSがCSPに対応して いて設定も簡単なので良い ○ アクセスが多いサイトはDatadogのほうが安いのでおすすめ ● Firefoxはreport-toに未対応なので、幅広いブラウザをカバー するためにreport-uriの併記か単体使用を推奨 report-toディレクティブのブラウザ別の対応状況： https://caniuse.com/mdn-http_headers_content-security-policy_report-to Step 2: レポート収集とポリシー改善 17 

ハッシュタグ #nikkei_tech_talk 1. Enforceモードで導入 ● Report-Onlyで違反レポートを潰したら、いよいよ本番適用 ● ヘッダー名を以下のように変更することで、ポリシー違反のリソー スはブロックされるように Step 3: 本番適用と継続的監視 18 Content-Security-Policy-Report-Only: ↓ Content-Security-Policy: 

ハッシュタグ #nikkei_tech_talk 2. 継続的なメンテナンス ● 新しい機能の追加や外部サービスの変更で、CSPは陳腐化する ● 定期的にレポートを監視し、サイトの更新に合わせてアップデート をしていく ○ フレームワークやCI/CDによる自動化も検討 Step 3: 本番適用と継続的監視 19 

ハッシュタグ #nikkei_tech_talk ● 許可リストには、バイパスのリスクが常に付きまとう ● 以下のポリシーは見た目は安全そうだが… Tips: CSPバイパス 20 Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google.com 

ハッシュタグ #nikkei_tech_talk ● 許可リストには、バイパスのリスクが常に付きまとう ● 以下のポリシーは見た目は安全そうだが… →実はCSPバイパスが可能 Tips: CSPバイパス 21 Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google.com 

ハッシュタグ #nikkei_tech_talk 以下のような方法でCSPをバイパスすることが可能 ● 許可したドメイン配下に脆弱なスクリプトが存在 ○ reCAPTCHA関連の古いスクリプト（通常は使われない） ○ 既知の脆弱性が存在するAngularJSが内包 ● 緩和策： ○ 公開CDNを使用しない、ドメイン単位→パス単位で許可など Tips: CSPバイパス 22 

ハッシュタグ #nikkei_tech_talk ● あらかじめ各Stepで具体的な導入期間を設定すること ○ EnforceまでのStepは長引きがちなので、期間を決めて集中 して取り組む ○ unsafe-inlineの排除などは別途期間を設けると良い ● 積極的に開発チームをサポートする ○ CSPは複雑なので、そこがネックで取り組みが遅くなることも ○ 有識者がSlackやMTGで積極的にコミュニケーション ● プロダクトごとに現実的なポリシーの設計を ○ 非現実的なポリシー設計をすると導入はなかなか進まない 日経でCSPを導入・検討してみて感じたこと 23 

ハッシュタグ #nikkei_tech_talk ● CSP導入はXSSに対する多層防御の最後の砦 ● CSPは段階的に導入できる まとめ 24 

ハッシュタグ #nikkei_tech_talk ● CSP未導入の方： ○ Report-Onlyの導入を社内PoCで実施 ● CSP導入済みの方： ○ 現状のCSPヘッダーを見直し、より堅牢なポリシーへの移行を 検討（unsafe-inline→許可リスト、許可リスト→nonce） 次の一歩 25 

付録 26 

ハッシュタグ #nikkei_tech_talk ● CSP Evaluator ○ https://csp-evaluator.withgoogle.com/ ○ Google公式のポリシーチェッカー ○ CSPバイパスも検出してくれる 便利系ツール 27 

ハッシュタグ #nikkei_tech_talk ● コンテンツセキュリティポリシー (CSP) - HTTP | MDN ○ https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/CSP ○ CSPの概要を手っ取り早く知りたいときにおすすめ ● Content Security Policy Level 3 ○ https://www.w3.org/TR/CSP3/ ○ MDNよりも詳しい情報が得られる ● w3c/webappsec-csp | GitHub ○ https://github.com/w3c/webappsec-csp/issues ○ 新しいディレクティブや今後のアップデートを最速で キャッチアップ系 28 

ハッシュタグ #nikkei_tech_talk ● 厳格なコンテンツ セキュリティ ポリシー（CSP）を使用してクロスサイト スクリプ ティング（XSS）を軽減する | Articles | web.dev ○ https://web.dev/articles/strict-csp?hl=ja ○ Strict CSPについて解説する記事 ● nonce - HTML | MDN ○ https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Global_attributes/ nonce ○ nonce属性について解説する記事 Strict CSP系 29 

ハッシュタグ #nikkei_tech_talk Content-Security-Policy: default-src 'self'; upgrade-insecure-requests; base-uri 'none'; connect-src 'self' https://api.example.com; form-action 'self'; frame-ancestors 'none'; img-src 'self' data: https://image-assets.example.com; object-src 'none'; script-src 'self' https://script-assets.example.com; style-src 'self' 'unsafe-inline' https://style-assets.example.com; report-uri 許可リストの設定例（緩め） 30 

ハッシュタグ #nikkei_tech_talk Content-Security-Policy: default-src 'none'; upgrade-insecure-requests ; base-uri 'none'; connect-src 'self' https://www.example.com; font-src https://font-assets.example.com; form-action 'self'; frame-ancestors 'none'; frame-src https://frame.example.com; img-src 'self' data: https://media-assets.example.com; manifest-src 'self'; script-src https://script-assets.example.com; style-src https://style-assets.example.com; report-uri 許可リストの設定例（厳しめ） 31 

32 ご清聴ありがとうございました！