【テクニカル・上級編】Content-Security-Policy (CSP) のscript-srcディレクティブによる実行制御 – アプリケーションセキュリティ & 安全な開発防御ガイド

CSPは「魔法の杖」ではない：script-srcの深淵と、モダンWebの防御アーキテクチャ

多くのエンジニアがCSP（Content Security Policy）を「XSSを防ぐための単なるヘッダー」だと誤解している。だが、現場でインシデント対応の最前線に立つ我々にとって、CSPは攻撃者のOSI参照モデルレイヤー7における「最後の砦」であり、同時に設定ミス一つでいとも簡単に突破される「脆い防壁」でもある。

今日は、script-srcディレクティブの本質と、それがなぜプロンプトインジェクションの時代において再評価されるべきなのか、その核心を突く。

—

1. 「信頼できるドメイン」という幻想

多くの組織が設定する script-src 'self' https://trusted.cdn.com というポリシー。これを見て「安全だ」と思うのは素人だ。

攻撃者は、CDN上にホストされた「正当なライブラリ」の中に存在する「ガジェット」を狙う。例えば、古いバージョンのAngularJSや、特定のjQueryプラグイン。これらは正当なドメインから読み込まれているため、CSPのホワイトリストをすり抜ける。これが、パケット解析や静的解析では防ぎきれない、アプリケーション層の盲点だ。

対策の核心:
単なるドメイン制限ではなく、strict-dynamic と nonce（使用回数制限付きの使い捨てトークン）の併用が現代の標準だ。

推奨される厳格なCSPヘッダーの例
Content-Security-Policy:
default-src ‘none’;
script-src ‘nonce-EDNnf03nceIOfn39fn3e9h3sdf’ ‘strict-dynamic’ https:;
object-src ‘none’;
base-uri ‘none’;

• nonce: サーバー側で生成したランダムな文字列。HTML内の