【実務・中級編】CSPにおけるnonce（ナンス）を用いたインラインスクリプトの制御 – アプリケーションセキュリティ & 安全な開発防御ガイド

CSPの「nonce」こそが、XSSという悪夢を終わらせる最後の砦だ

現場でコードを書いていて、「XSS対策？エスケープ処理は完璧だよ」なんて言葉を耳にすると、私は正直ヒヤリとする。なぜなら、現代のフロントエンド開発において、エスケープ漏れは単なる「ミス」ではなく「必然」だからだ。フレームワークのバグ、サードパーティ製ライブラリの脆弱性、あるいは複雑すぎるDOM操作。これらを完璧に防ぎ切るのは人間業じゃない。

だからこそ、CSP（Content Security Policy）のnonce（ナンス）による制御が重要になる。これは「怪しいコードはそもそも実行させない」という、ゼロトラスト時代の鉄則そのものだ。

1. なぜ「エスケープ」だけでは足りないのか？（PoCのリスク）

例えば、以下のようなコードを考えてみてほしい。

// 攻撃者がURLパラメータを操作できる状況
const username = new URLSearchParams(window.location.search).get("name");
document.getElementById("welcome").innerHTML = "ようこそ、" + username + "さん";

攻撃者が ?name= と送り込めば、ブラウザはそのスクリプトを「信頼されたコードの一部」として実行してしまう。これが反射型XSSの典型だが、怖いのは、攻撃者が動的に外部スクリプトを読み込ませる（DOM型XSS）場合だ。

防御側が「全ての入力値をエスケープする」というルールを徹底していても、一箇所でも v-html や dangerouslySetInnerHTML のような「素通り」ポイントがあれば、ゲームオーバーだ。

2. nonceによる「実行許可リスト」の仕組み

nonce（Number used once）は、リクエストごとに生成される使い捨ての乱数だ。これをHTTPレスポンスヘッダーとHTML内の