CSPは「気休め」か「最後の砦」か ― インラインスクリプトを封じ込めるアーキテクチャの本質
多くの開発者がCSP（Content-Security-Policy）を「とりあえず設定しておくお守り」程度に考えているのを見てきた。だが、現場のインシデントハンドリングの最前線にいる人間から言わせれば、CSPはモダンWebアプリケーションにおける「ラストライン・オブ・ディフェンス（最後の防衛線）」であり、ここを突破されることは、すなわちアプリケーションの論理的破綻を意味する。
特に、今日のような複雑化したフロントエンド環境において、XSS（クロスサイトスクリプティング）は単なるアラート表示の脆弱性ではない。DOMベースの攻撃からプロトタイプ汚染を経由した実行権限の奪取、さらにはAIチャットボットのプロンプトインジェクションを介した機密情報の漏洩まで、攻撃のベクトルは常に進化している。
1. なぜ「ゆるい」CSPはゴミなのか
多くの現場で目にするのが、unsafe-inline を許可したCSPだ。これは、泥棒に「正面玄関の鍵は開けておくが、家の中には入るな」と言っているに等しい。XSSの脅威モデルにおいて、攻撃者が最も狙うのは「実行のコンテキスト」だ。
インラインスクリプトを許可すれば、反射型・蓄積型XSSは、ペイロードを注入された時点で即座に実行される。これを防ぐための唯一の解は、「ソースの信頼性をコード実行の瞬間にまで遡って証明すること」にある。
2. Nonceによる「一回限りの実行許可」の設計
現代の防御アーキテクチャでは、nonce（Number used once）を用いた厳格なポリシーが必須だ。これは、リクエストごとに生成されるランダムな文字列を、スクリプトタグに付与して一致を確認する手法である。
推奨される厳格なCSPヘッダーの例
Content-Security-Policy: default-src ‘self’; script-src ‘nonce-RANDOM_BASE64_TOKEN’ ‘strict-dynamic’; object-src ‘none’; base-uri ‘self’;
nonce-RANDOM_BASE64_TOKEN: サーバーサイドで生成し、HTMLレンダリング時に埋め込む。攻撃者が任意のスクリプトを注入しようとしても、この動的なnonceを推測することは不可能だ。strict-dynamic: これが肝だ。nonceが付与されたスクリプトから生成された子スクリプトも信頼するというオプションだが、これによりレガシーな外部ライブラリの読み込みを柔軟に制御しつつ、汚染された静的ソースの実行を排除できる。object-src 'none': Flashやプラグインによる古い攻撃手法を物理的に遮断する。いまだに存在するレガシーな脆弱性への対策だ。
3. 生成AI時代の新たな脅威：プロンプトインジェクションとCSP
最近のトレンドである「LLMを組み込んだWebアプリ」では、生成AIが吐き出したHTMLコードがそのままDOMに注入されるケースが増えている。これは、従来のXSSの概念を拡張した「プロンプトインジェクション経由のコード実行」だ。
攻撃者はLLMに対し「connect-src）がブロックされ、被害を最小限に食い止めることができる。
防衛の要点:
connect-srcで通信先をホワイトリスト化する。frame-ancestors 'none'でクリックジャッキングを無効化する。report-toまたはreport-uriを活用し、CSP違反をSIEM（セキュリティ情報イベント管理）にリアルタイムで収集する。
4. 監査と運用の泥臭い実態
CSPは「設定して終わり」ではない。新機能のデプロイでCI/CDパイプラインが壊れる原因の筆頭でもある。だからこそ、Content-Security-Policy-Report-Only モードを使い倒すべきだ。
本番環境で違反のみをレポートさせ、既存のライブラリや動的なスクリプト生成がポリシーと矛盾していないかを数週間かけてモニタリングする。その上で、統計的に弾き出された「正当な通信」のみを許可リストに昇格させる。この「運用によるチューニング」をサボるチームが、結局は運用負荷に耐えかねて unsafe-inline を解放してしまうのだ。
結び：アーキテクトとしての矜持
脆弱性対策とは、パッチを当てることではない。「攻撃者が、攻撃を実行するために必要なコスト（計算資源・時間・創造性）を、防衛側のコスト以上に引き上げること」だ。
CSPの厳格化は、攻撃者にとって「実行の不確実性」を最大化する。未知のCVE（脆弱性）がブラウザのレンダリングエンジンに見つかったとしても、CSPが堅牢であれば、即座に悪用されるリスクを劇的に低下させることができる。
コードを書くとき、サーバーを設定するとき、今一度自問してほしい。
「私の書いたこのポリシーは、未来の脆弱性からユーザーを守り抜く意志を持っているか？」
セキュリティは、技術の集積であると同時に、細部へのこだわりという「魂」の宿る場所だ。妥協のないアーキテクチャ設計こそが、我々エンジニアが守るべきデジタル世界の最後の防壁となる。
コメント