CSPは「最後の砦」ではない。それは「境界防御の終着点」だ
現場でインシデント対応をしていると、多くのテックリードがCSP（Content-Security-Policy）を「とりあえず入れておけば安心」な免罪符だと誤解していることに気づく。だが、現実は冷酷だ。script-src 'unsafe-inline' を許可した瞬間、あなたのXSS対策は砂上の楼閣と化す。
今日は、教科書的な説明は省く。攻撃者がどのようにメモリレイアウトを操作し、ブラウザのパーサーを欺き、CSPをバイパスしてくるのか。その「泥臭い現実」と、防衛アーキテクトが打つべき一手について語ろう。
—
1. CSPを「殺す」攻撃者の常套手段：DOM-based XSSの核心
攻撃者は、CSPが有効な環境であっても、アプリケーション内の「正当なスクリプト」を悪用する。これを「ガジェット（Gadgets）」と呼ぶ。例えば、jQueryの古いバージョンや、Vue/Reactの特定のコンポーネントが、URLフラグメントからDOMを動的に生成する挙動をしていれば、eval() を使わずに任意コードを実行できてしまう。
この時、CSPは「信頼されたドメインからの読み込み」を許可しているため、無力だ。これを防ぐには、単純なホワイトリスト方式から、「Nonce（ナンス）ベース」または「Strict CSP」への脱却が不可欠だ。
実装すべき最強の CSP ディレクティブ設定
現代のアーキテクチャでは、ドメインのホワイトリスト運用は諦めろ。ドメインのリストは、CDNのホスティングやサードパーティの依存関係が複雑化した現代では、メンテナンス不可能な脆弱性そのものだ。
以下の設定は、モダンブラウザにおける「Strict CSP」の骨子だ。
# 厳格なCSPヘッダーの例
Content-Security-Policy:
default-src 'self';
# nonce付きのスクリプトのみ許可し、unsafe-inlineを禁止
script-src 'nonce-R4nd0mSt4rt3r' 'strict-dynamic' 'self';
# object-srcは必ずnoneにする（古いプラグインの脆弱性を封じるため）
object-src 'none';
# base-uriを制限して、スクリプトのパス固定攻撃を防ぐ
base-uri 'self';
# HTTPSへの強制移行と混在コンテンツのブロック
upgrade-insecure-requests;'strict-dynamic': これが肝だ。Nonceが付与されたスクリプトが動的に読み込む依存ライブラリを自動的に信頼させる。これにより、大規模なアプリケーションでも、一つひとつのスクリプトにNonceを振る地獄から解放される。'nonce-...': サーバーサイドでリクエストごとに生成する暗号論的に安全な乱数だ。これがインジェクションされたタグと一致しなければ、ブラウザは即座に実行を拒絶する。
—
2. 暗号基盤との融合：なぜ「Nonce」が最強の防衛か
なぜNonceなのか？ それは、暗号理論における「使い捨て（One-time）」の原則を、ブラウザのDOMレンダリング層に持ち込んでいるからだ。
攻撃者がプロンプトインジェクションを通じてLLMやWebアプリの出力を改ざんしようとしても、nonce を推測することはできない。CSPは、ブラウザがメモリ上でHTMLをパースする際、スクリプトタグの属性値と、HTTPヘッダーに埋め込まれた値を比較する。この「コンテキストの検証」こそが、低レイヤでのメモリ破壊を伴う攻撃に対する、最もコストパフォーマンスの良い防衛策だ。
—
3. 生成AI時代の新たな境界：LLMインジェクションへの防御
最近の懸念は、LLMが生成したコードがアプリケーションに直接注入されることだ。LLMは「正しそうに見えるが危険なコード（例: dangerouslySetInnerHTML の安易な使用）」を平気で出力する。
ここで重要になるのが、「CSPの違反レポート（Report-Onlyモード）」の継続的な監査だ。
// 違反レポートを監視するエンドポイントのロジック（簡易版）
app.post('/csp-violation-report', (req, res) => {
const report = req.body;
// 実際に攻撃が発生しているか、あるいは開発者の実装ミスかを分析
// ここでSIEM（SplunkやDatadog）に飛ばし、異常なNonceの使用をアラートする
console.error('CSP Violation Detected:', report['csp-report']);
res.status(204).end();
});このレポートを無視しているプロジェクトは、いつか必ず踏み抜く。異常な場所からのスクリプト実行、あるいは不審な base-uri へのアクセスを検知することで、攻撃者が「偵察（Reconnaissance）」を行っている段階で叩き潰すことが可能だ。
—
4. 最後に：アーキテクトへの問い
セキュリティは「設定」ではなく「規律」だ。
1. object-src 'none' を徹底しているか？ （Flashなどのレガシーなバイナリプラグインは、ブラウザのメモリ領域を汚染する最大の入り口だ）
2. base-uri 'self' を設定しているか？ （これがないと、攻撃者は <base href="https://attacker.com"> を挿入することで、相対パスのスクリプトをすべて奪取できる）
3. 耐量子暗号（PQC）への移行準備はできているか？ （RSA/ECCが将来的に破られる前提で、TLS層での鍵交換アルゴリズムの更新計画を立てているか？）
CSPは銀の弾丸ではない。しかし、強固なCSPを設定することは、攻撃者があなたの城壁を登るために必要な「コスト」を、彼らが諦めるレベルまで引き上げる行為だ。
防衛とは、完璧を目指すことではない。攻撃者のROI（投資対効果）を破壊することだ。今日から設定を見直し、'unsafe-inline' の文字をコードベースから駆逐してほしい。それが、プロのエンジニアが取るべき最初の一手だ。
コメント