CSPとは何で、なぜスクリプトを止めるのか
Content-Security-Policy(CSP)は、ブラウザがどこから読み込んだスクリプト・スタイル・画像などを実行・適用してよいかを宣言するセキュリティ機能です。XSS(クロスサイトスクリプティング)対策として、許可していないコードの実行を未然に防ぐ役割を持ちます。
CSPはHTTPレスポンスヘッダで指定するのが本来の形ですが、HTML内の meta http-equiv 要素でも一部のディレクティブを宣言できます。AIが生成したHTMLやテンプレートには、この meta によるCSPが入っていることがあり、それが意図せず厳しすぎる設定になっているケースが目立ちます。
ポイントは、CSPは「デフォルトで拒否、明示的に許可」という発想で動くことです。一度 script-src を指定すると、そこに含めていない読み込み元やinlineコードは一律でブロックされます。
inline scriptがブロックされる典型パターン
最も多いのは、script-src に 'self' だけを書いているのに、HTML内に直接 script タグでコードを書いている(inline)パターンです。'self' は同一オリジンの外部ファイルは許可しますが、inlineコードは許可しません。
同様に onclick などのHTML属性に書いたイベントハンドラもinline扱いとなり、'unsafe-inline' を許可しない限り実行されません。style属性やstyleタグも style-src の制約を受け、レイアウトが崩れる原因になります。
コンソールに表示される「Refused to execute inline script because it violates the following Content Security Policy directive」という文言が、CSP起因かどうかの判断材料になります。違反したディレクティブ名もそこに書かれています。
症状別チェック表
CSPでJS/CSSがブロックされるは、症状を分けずに直そうとすると原因探しが長引きます。まず「自分だけで起きるのか」「全員で起きるのか」「特定ブラウザだけか」「差し替え後だけか」を切り分けます。
確認順序を固定すると、相対パス、ファイル名、キャッシュ、認証、外部読み込みのどこで止まっているかが見えます。修正後はローカル確認だけで終わらせず、実際の共有URLで再表示して、相手と同じ条件で直ったことを確認します。
- 自分だけ表示されない: キャッシュ、ログイン状態、ブラウザ拡張、端末幅を確認する
- 全員で表示されない: ファイル構成、相対パス、大文字小文字、アップロード漏れを見る
- 一部だけ崩れる: CSS/画像/JSごとに読み込みエラーを分ける
- 差し替え後だけ古い: URL、キャッシュ、更新対象ファイルの取り違えを確認する
ブロックを解消する手順
原因を特定したら、設計方針に合わせて段階的に直します。安易に何でも許可するのではなく、必要最小限の緩和にとどめるのが安全です。
- ブラウザの開発者ツールを開き、Consoleタブで違反メッセージとブロックされたディレクティブ名を確認する
- HTMLの head 内にある meta http-equiv="Content-Security-Policy" の記述を探す
- inlineコードを外部jsファイルに切り出し、script-src 'self' で読み込めるようにする(最も推奨)
- 外部切り出しが難しい場合は、該当scriptに nonce 値を付けて script-src に 'nonce-...' を追加する
- 暫定対応として 'unsafe-inline' を加える場合は、検証用に限定しXSSリスクを理解した上で行う
- 修正後にページを再読み込みし、コンソールに違反が残っていないか再確認する
metaタグCSPとヘッダCSPの違いに注意
meta によるCSPは便利ですが、frame-ancestors のように meta では効かないディレクティブが存在します。埋め込み制御をmetaで書いても期待通りに動かないことがあるため、本来はヘッダで指定するのが確実です。
また、ヘッダとmetaの両方でCSPが指定されている場合、両者は加算的に適用され、結果として最も厳しい制約が効きます。片方を緩めたつもりでももう片方が効いていてブロックが解けない、という混乱も起こりがちです。
確認・共有用のページでは、まずmetaのCSP記述を見直すのが手早い対処になります。配信側でヘッダを付与している環境では、その挙動も合わせて把握しておくと切り分けが速くなります。
確認共有の場面で気をつけたいこと
クライアントや社内レビューにHTMLを共有して「動かない」と言われたとき、相手の環境ではなくHTML自体のCSPが原因のことがあります。共有前に自分の手元で開発者ツールを開き、コンソールにCSP違反が出ていないか確認しておくと、無用なやり取りを減らせます。
ギガサイト便はHTMLファイルやZIPをドロップするとそのまま共有URLを発行できるため、修正したHTMLを同じURLのまま差し替えて再確認してもらえます。CSPを直すたびにリンクを送り直す手間がかからないので、ブロック解消の試行錯誤と相性が良い使い方です。
よくある質問
CSPを完全に外せばブロックは解決しますか
metaのCSP記述を削除すればブロックは解消しますが、XSSへの防御も失われます。検証目的の一時的な削除は許容できても、公開する内容では必要なディレクティブを残し、最小限の許可で動かす設計が安全です。
'unsafe-inline' を付ければ全部動きますか
inline scriptやinline styleは動くようになりますが、CSPの保護効果が大きく下がります。可能ならコードを外部ファイルに切り出すか nonce/hash を使う方が、安全性を保ったままブロックを解消できます。
コンソールに違反が出ているのにページは普通に見えます。直す必要はありますか
見た目のHTMLが表示できても、ブロックされたスクリプトに依存する機能(送信処理や動的表示など)は動いていません。レビュー前に全機能を一通り操作し、CSP違反が残っていないか確認することをおすすめします。
CSPの違反かどうかをどう見分ければよいですか
ブラウザの開発者ツールのConsoleに「violates the following Content Security Policy directive」という文言が出ていればCSP起因です。あわせて違反したディレクティブ名(script-srcなど)が表示されるので、どこを緩めるべきか判断できます。
原因が分からないときはどこから確認すべきですか？
まず自分だけの問題か全員の問題かを分けます。次にシークレットウィンドウ、別ブラウザ、スマホで確認し、ファイル構成・相対パス・キャッシュ・認証設定を順に見ます。