【テクニカル・上級編】Content-Security-Policy (CSP) の設計と厳格なポリシー適用 – アプリケーションセキュリティ & 安全な開発防御ガイド

XSSの牙城を崩す：Content Security Policy (CSP) による鉄壁の防御設計

Webアプリケーションのセキュリティ、特にクロスサイトスクリプティング（XSS）の脅威は、もはや古典的でありながら、未だに多くのシステムを蝕む根深い問題だ。CVEとして日々報告される脆弱性の多くは、このXSSの範疇に収まるか、その派生形である。我々が日々格闘しているのは、単なるコードのバグではない。そこには、HTTPプロトコルの仕様の隙間を突く巧妙な手法、ブラウザのレンダリングエンジンの挙動を逆手に取るトリッキーな攻撃、そして何より、攻撃者の「常識」を覆すような発想が潜んでいる。

本稿では、OWASP Top 10の最前線に立ち続けるXSS対策の切り札、Content Security Policy（CSP）に焦点を当てる。単なる「設定しておけば安心」という甘い言葉に騙されてはならない。真のセキュリティアーキテクト、チーフホワイトハッカー、そしてテックリードが実践すべき、CSPの設計思想、厳格なポリシー適用のためのディープな技術、そして最新の動向について、現場の生々しい知見と、攻撃者の視点から徹底的に掘り下げていく。

CSPの核心：信頼の連鎖を断ち切る「許可リスト」思想

XSS攻撃の根源は、信頼されていない（あるいは信頼性が低い）ソースからのスクリプトが、ユーザーのブラウザ上で実行されてしまうことにある。攻撃者は、この「信頼」の隙間を縫って、悪意あるJavaScriptを注入し、セッションハイジャック、情報窃取、フィッシングサイトへのリダイレクトといった、おぞましい所業を働く。

CSPは、この問題を根本から解決するために、「デフォルト拒否」の原則に基づき、明示的に許可されたリソースのみをロード・実行できるようにすることで、ブラウザの挙動を制御する。これは、従来のような「ブラックリスト」（悪意あるものを列挙して排除する）アプローチの限界を突破し、「ホワイトリスト」（安全なものを列挙して許可する）という、より堅牢なセキュリティモデルを実装するための強力なメカニズムだ。

HTTPレスポンスヘッダーに `Content-Security-Policy` を追加することで、ブラウザにどのようなリソースをどこからロードして良いかを指示する。

Content-Security-Policy: default-src ‘self’; script-src ‘self’; object-src ‘none’;

このシンプルな例でも、その意図は明確だ。

• `default-src ‘self’`: 全てのリソース（スクリプト、スタイルシート、画像、フォントなど）のデフォルトの取得元を、同一オリジン（`’self’`）に制限する。
• `script-src ‘self’`: JavaScriptの実行元を、同一オリジンに限定する。
• `object-src ‘none’`: `