XSSの「終焉」を設計する：CSP nonceによるインラインスクリプトの完全統治
世界中のエンジニアが未だに「XSSはサニタイズで防ぐもの」という呪縛に囚われているのを見るたび、私は溜息が出る。入力をエスケープする？ htmlspecialcharsを適切に使う？ それは対症療法に過ぎない。現代のフロントエンド開発において、依存ライブラリの汚染やサードパーティタグの混入を完全にゼロにすることは不可能だ。
真のセキュリティアーキテクトが目指すべきは、「コードが注入されても、決して実行させない」という強固な実行ポリシーの強制である。その最前線にあるのが、Content Security Policy (CSP) レベル3で実装されるnonce（number used once）のアーキテクチャだ。
1. なぜ「スクリプトの暗黙的実行」を殺す必要があるのか
XSSの根本的な脅威は、ブラウザが「HTML内に記述された
3. チーフホワイトハッカーが指摘する「盲点」
多くの開発者がここで躓くのが、'strict-dynamic'の解釈だ。
現代のアプリケーションは、メインのバンドルファイルから動的に別のスクリプトを読み込む（document.createElement('script')等）。'strict-dynamic'を付与しないnonceベースのCSPでは、これらが全てブロックされ、画面が真っ白になる。
strict-dynamicの真価: nonceが付与された「信頼されたスクリプト」が動的に生成した追加のスクリプトに対して、その信頼を継承させる。これにより、柔軟なフロントエンド開発と強固なセキュリティを両立できる。- 回避策としてのインジェクション:
unsafe-inlineを併用する場合、nonceがあればブラウザはunsafe-inlineを無視する仕様になっている。これを利用して、古いブラウザとの互換性を保ちつつ、モダンブラウザでセキュリティを強化する多重防衛（Defense in Depth）を構築せよ。
4. 次世代への備え：プロンプトインジェクションとの交差点
我々が直面している新たな脅威は、生成AIの出力がそのままWebページにレンダリングされることで発生する「AIプロンプトインジェクションによるXSS」だ。
LLMが生成するレスポンスに、攻撃者が誘導したJavaScriptが含まれていた場合、従来のバリデーションは無力化する。ここでnonceベースのCSPが唯一の防御層となる。LLMの出力結果をinnerHTMLに流し込む際、もしそこに悪意あるスクリプトが混入していても、サーバーサイドのnonceが付与されていない限り、ブラウザはそのコードを「無害な文字列」として扱う。
結論：技術的負債ではなく、セキュリティ負債を返済せよ
nonceを導入することは、アプリケーション全体のアーキテクチャを「インラインスクリプトの禁止」という厳格な規律の下に置くことを意味する。これは一見すると開発工数の増大に思えるが、実は「コードの断片化」を防ぎ、保守性を高める絶好の機会だ。
セキュリティとは、パッチを当てることではない。攻撃者のパスを遮断し、ブラウザの挙動をこちら側の意図通りに制御することだ。貴殿のシステムにnonceを導入せよ。それだけで、貴殿のアプリケーションは世界中の脆弱性ランキングのトップ層から脱落する資格を得ることになる。
もし、貴殿のチームが「実装が面倒だ」と言うならば、こう答えてやってほしい。「XSSで顧客のトークンが漏洩するコストと、今ここで設計を見直すコスト、どちらが安いか？」と。
コメント