CSPでunsafe-evalを許可していないか？危険な理由・ブロックされる処理・削除手順

CSPでunsafe-evalを許可していないとは

CSPでunsafe-evalを許可していないとは、Content Security Policy（CSP）のスクリプトに適用されるディレクティブで、'unsafe-eval' が許可されておらず、文字列をJavaScriptのコードとして実行する処理（eval系）がブロックされている状態のことです。

'unsafe-eval' は、次のような機能をCSPの下で許可するキーワードです。

• eval()
• new Function()（Function() コンストラクター）
• 文字列を渡した setTimeout()／setInterval() など

CSPが有効でも 'unsafe-eval' があると、攻撃者がDOMに注入した文字列やURLのパラメーターが、ライブラリの評価処理を経由してコードとして実行される経路が残ります。

# 危険：eval 系の実行が許可されている
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' https:

セキュリティAIチェッカーのこの項目は、スクリプトに適用される有効なディレクティブでeval系の実行が許可されていないかを確認します。インラインスクリプトの許可は「CSPでunsafe-inlineを許可していない」、CSPそのものの有無は「Content Security Policy」で確認します。

unsafe-evalは何を許可するのか（仕組み）

unsafe-evalが制御する処理

MDN（script-src）によれば、CSPがあり script-src に 'unsafe-eval' がない場合、次の処理はブロックされます。

WebAssemblyのコンパイル・実行は、別のキーワード 'wasm-unsafe-eval' で制御されます。'unsafe-eval' を指定すると、それも包含して許可されます。WebAssemblyだけが必要なら 'wasm-unsafe-eval' を使うのが最小権限です。

eval判定に使われるディレクティブ

eval系の判定には script-src が使われ、なければ default-src にフォールバックします。script-src-elem はeval判定には使われないと、CSP3に明記されています。したがって次のような違いがあります。

nonceや 'strict-dynamic' では打ち消されない

'unsafe-inline' と違い、'unsafe-eval' はnonce・hash・'strict-dynamic' があっても無効化されません。strict CSPに移行したつもりでも、'unsafe-eval' が残っていればeval系の実行は許可されたままです。

Next.js公式ガイドでも、開発時（React開発版のデバッグ機能）だけ 'unsafe-eval' が必要で、本番では不要と説明されています。

unsafe-evalについてよくある誤解

• 「evalを使っていないから 'unsafe-eval' があっても無害」：自前のコードで使っていなくても、古いテンプレートライブラリやjQueryプラグインの一部は、文字列評価を内部で行います。許可しておくと、それらがDOM XSSの踏み台になります。
• 「'unsafe-eval' を消すと必ず壊れる」：近年の主要フレームワークの本番ビルドはevalを必要としないものが多く、実際に何が使っているかはReport-Onlyで確認できます。

CSPでunsafe-evalを許可していないの診断基準（セキュリティAIチェッカー）

取得対象

• トップページの最終応答の Content-Security-Policy ヘッダー（カンマ区切りの複数ポリシーを個別に評価）を取得します。
• HTML内のmeta CSPも対象にします。

判定ロジック

1. 各ポリシーのスクリプト用リストを、script-src、なければ default-src とします。
2. リストが存在しない（無制限）、または 'unsafe-eval' を含むポリシーは「evalを許可」とします。
3. 複数のポリシーは全ポリシーの許可が必要なため、すべてのポリシーが許可している場合に×とします（1つでも禁止するポリシーがあれば、ブラウザはブロックします）。
4. 'wasm-unsafe-eval' は 'unsafe-eval' とは別のキーワードとして扱い、この項目では問題にしません。

判定条件

△（warn）は使いません。evalの許可は有無の二択であり、部分的な許可という状態がないためです。

判定の限界

• この項目は、ヘッダーとmetaに書かれた宣言だけを評価します。サイトのJavaScriptが実際にevalを使っているか、どのライブラリが文字列評価を行うかは、ソースコードの確認やReport-Onlyでの実測が必要です。
• 診断するのはトップページ1ページです。申請フォームや地図ページなど、ページ単位で別のCSPを送っている場合は、それらのページも個別に確認してください。
• Report-Only ヘッダーの 'unsafe-eval' は遮断に影響しないため評価しません。

自治体サイトでの判定例

unsafe-evalを許可しているとどんなリスクがあるか

• DOM XSSの成立：URLのハッシュやクエリの値を、テンプレート処理や setTimeout(文字列) に渡す実装があると、攻撃者は細工したリンクで任意のコードを実行できます。CSPが 'unsafe-eval' を許可していると、この経路をブラウザが止めません。
• CSPバイパスの足がかり：許可済みドメインにあるライブラリ（テンプレートエンジン系）を読み込ませ、そのライブラリが内部で文字列評価を行う「スクリプトガジェット」型のバイパスは、evalを禁止することで成立しにくくなります。
• 想定される被害：入力フォームの内容の窃取、偽画面の表示、管理画面を開いた職員のセッションでの不正操作など。

CSPを入れていても 'unsafe-eval' が残っていれば、文字列評価を行うライブラリが読み込まれている限り、これらの経路はブラウザ側で止まりません。

unsafe-evalを削除する方法（コード修正・Apache・nginx・IIS・Next.js）

削除までの手順

1. Report-Onlyで使用箇所を特定：'unsafe-eval' を外したポリシーをReport-Onlyで配信し、違反（effective-directive が script-src、blocked-uri が eval）を収集します。CSP3では、evalのブロックは "eval" として報告されます。
2. コード修正：
   • eval(json文字列) → JSON.parse()
   • setTimeout("処理()", 1000) → setTimeout(処理, 1000)
   • new Function(...) によるテンプレート → 事前コンパイル型のテンプレートやDOM APIに置き換え
3. ライブラリ更新：古いjQueryプラグイン、テンプレートライブラリ、地図・グラフ部品を、CSP対応版へ更新します。
4. WebAssemblyのみ必要なら 'wasm-unsafe-eval' に置き換えます。
5. 強制ヘッダーから 'unsafe-eval' を削除します。

JavaScriptの修正例

// 変更前
var data = eval('(' + text + ')');
setTimeout("refreshNews()", 5000);
// 変更後
var data = JSON.parse(text);
setTimeout(refreshNews, 5000);

Apache（.htaccess）

移行期間は、現行の強制ポリシー（'unsafe-eval' あり）を維持したまま、'unsafe-eval' を外した案をReport-Onlyで併走させると、表示を壊さずに影響を測れます。

<IfModule mod_headers.c>
  # 現行（強制）
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval' https://www.googletagmanager.com; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
  # 改善案（報告のみ）
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; object-src 'none'; base-uri 'self'; report-uri https://www.example.lg.jp/csp-report.php"
</IfModule>

違反がなくなったことを確認したら、強制側から 'unsafe-eval' を削除します。

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

既存の値に 'unsafe-eval' が含まれていないか、配下のディレクトリの .htaccess で上書きしていないかも確認してください。

nginx

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

IIS

<add name="Content-Security-Policy" value="default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" />

Next.js（Vercel）

公式ガイドのとおり、'unsafe-eval' は process.env.NODE_ENV === 'development' のときだけ付与します。

const isDev = process.env.NODE_ENV === 'development';
const scriptSrc = `script-src 'self' 'nonce-${nonce}' 'strict-dynamic'${isDev ? " 'unsafe-eval'" : ''}`;

本番ビルドで 'unsafe-eval' が残っていないか、デプロイ後のレスポンスヘッダーで確認します。

CMS・外部サービスが要求する場合

CMSのテーマや外部ウィジェット（地図、チャット、アンケート）が 'unsafe-eval' を要求する場合は、ベンダーにCSP対応状況を確認します。どうしても必要な場合は、そのウィジェットを使うページだけに限定したポリシーにし、サイト全体には付けないようにします。

設定後の確認方法

curl -sI https://www.example.lg.jp/ | grep -i '^content-security-policy' | grep -io "'unsafe-eval'"

何も表示されなければ、強制ヘッダーに 'unsafe-eval' はありません。ブラウザでは、開発者ツールのコンソールに「Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source」が出ないことを主要ページで確認します。

よくある質問（FAQ）

参考資料

• W3C Content Security Policy Level 3
• MDN CSP: script-src
• OWASP Content Security Policy Cheat Sheet
• OWASP ASVS 5.0 V3 Web Frontend Security
• OWASP WSTG-CONF-12 Test for Content Security Policy
• Mozilla HTTP Observatory Scoring
• Next.js「Content Security Policy」ガイド
• IPA「安全なウェブサイトの作り方」

「CSPでunsafe-evalを許可していない」と関連する診断項目

• CSPでunsafe-inlineを許可していないhigh
• Content Security Policyhigh
• CSPのdefault-srcmedium
• 危険なJavaScript APIの兆候high
• CSPがレスポンスヘッダーで強制されているhigh
• CSPの過剰なワイルドカードhigh
• CSPでHTTP配信元を許可していないhigh
• CSP違反の報告先low