CSPの過剰なワイルドカードとは？* や https: が危険な理由・検出条件・配信元の絞り込み方

CSPの過剰なワイルドカードとは

CSPの過剰なワイルドカードとは、Content Security Policy（CSP）の配信元リストに *（全オリジン）や https:（HTTPSならどこでも）などを書いた結果、そのディレクティブが事実上何も制限しなくなっている状態のことです。

# 危険：スクリプトをどこからでも読み込める
Content-Security-Policy: default-src * 'unsafe-inline' 'unsafe-eval'

特にスクリプトの配信元が広すぎると、攻撃者が自分で用意したHTTPSサイトや、誰でもファイルを置ける共有CDN上のスクリプトを読み込ませることができ、CSPを入れている意味が失われます。

セキュリティAIチェッカーのこの項目は、次の2種類を検出します。

1. 全オリジンを許可するワイルドカード（*、https://* など）
2. スクリプトに対するスキーム全体の許可（https:、http:、data:）

*.example.lg.jp のようなサブドメインに限ったワイルドカードは、範囲が自組織に限られるため対象外です。

なぜCSPのワイルドカードは危険なのか（仕組み）

* が許すもの

W3C CSP3 のURL照合アルゴリズムでは、ソース式 * は「URLのスキームがHTTP(S)」または「保護対象ページと同じスキーム」であれば一致します。つまり script-src * は、インターネット上のあらゆるHTTP／HTTPSサーバーからのスクリプトを許可します。data:・blob: などは、明示しない限り含まれません。https://* も同様に、全HTTPSホストを意味します。

スキームだけのソース（https: / http: / data:）

https: のようにスキームだけを書いたソース式は、そのスキームの全URLに一致します。

Mozilla HTTP Observatory の実装は、script-src／object-src における *、http:、https:、ftp:、https://* などを「過度に広い配信元」とし、data: をスクリプトに許可することも 'unsafe-inline' と同等の危険として扱っています。data: を許すと、<script src="data:text/javascript,..."> という形で任意のコードを実行できるためです。

'strict-dynamic' との関係

script-src に 'strict-dynamic' がある場合、対応ブラウザは、そのリスト内のホスト許可・スキーム許可・'self'・'unsafe-inline' を無視し、nonce／hashで信頼したスクリプトだけを起点にします。Google推奨のstrict CSPでは、非対応ブラウザ向けのフォールバックとして https: を併記する書き方が使われるため、この場合の https: は問題としません。

ディレクティブごとのワイルドカードの影響

CSPのワイルドカードについてよくある誤解

• 「https: だから安全」：HTTPSは通信の暗号化を保証するだけで、配信元が信頼できることは保証しません。攻撃者も、無料で証明書付きのサイトを用意できます。
• 「img-src * は画像だけだから問題ない」：XSSが起きた際、画像リクエストのURLにデータを載せて外部へ送る手口に使われます。業務上必要なら把握した上で許可し、可能な範囲で絞り込みます。

平文HTTPの配信元そのもの（http://… や http:）は「CSPでHTTP配信元を許可していない」、default-src の有無は「CSPのdefault-src」でも評価します。

CSPの過剰なワイルドカードの診断基準（セキュリティAIチェッカー）

取得対象

• トップページの最終応答の Content-Security-Policy ヘッダー（カンマ区切りの複数ポリシーを個別に分解）と、HTML内のmeta CSPを対象にします。
• 各ポリシーを ; で分割し、トークンを小文字化して評価します。

検出条件

1. 全オリジン許可のワイルドカード：任意のディレクティブの値に、*、https://*、http://*、*:* のように、ホスト部全体が * のソース式がある。ただし、'strict-dynamic' を含む script-src 系のディレクティブは、ホスト許可が無視されるため除外します。
2. スクリプトへのスキーム全体の許可：有効なスクリプト用リスト（script-src、なければ default-src）に https:、http:、data: がある。ただし、同じリストに 'strict-dynamic' がある場合は除外します。

判定条件

*.example.lg.jp のようなサブドメインのワイルドカード、https://cdn.example.com のような具体的なオリジンは対象外です。http: の配信元そのものは「CSPでHTTP配信元を許可していない」でも評価します。

自治体サイトでの判定例

frame-ancestors * の埋め込み許可は、「クリックジャッキング対策」で×として扱われます。

CSPのワイルドカードが過剰だとどんなリスクがあるか

• CSPバイパス：script-src に https: や * があると、XSSの注入点で <script src="https://攻撃者のサイト/x.js"> を読み込ませるだけで、任意のコードが実行できます。CSPを入れているのに、実質無防備という状態です。
• 公開CDN経由のバイパス：広い許可に、誰でもファイルを置ける公開CDNが含まれると、そこに置かれた古いライブラリを悪用される手口が知られています。
• 情報流出：connect-src *、img-src * は、XSS時に入力内容や画面情報を任意の外部サーバーへ送る経路になります。
• クリックジャッキング：frame-ancestors * は、X-Frame-Optionsを無効化したうえで、どのサイトからの埋め込みも許します。

CSPのワイルドカードを絞り込む方法（Apache・nginx・IIS・Next.js）

修正の手順

1. 実際の配信元を把握：ブラウザの開発者ツール（ネットワーク）やReport-Onlyの違反レポートで、各種類のリソースの配信元ドメインを一覧にします。
2. 具体的なオリジンへ置き換え：* や https: を、https://www.googletagmanager.com、https://maps.googleapis.com など、実際に必要なオリジンへ置き換えます。
3. スクリプトはnonce方式を検討：外部タグが多く許可リストが長くなる場合は、'nonce-…' 'strict-dynamic' によるstrict CSPに移行すると、ホスト許可リストに頼らずに済みます。
4. Report-Onlyで確認してから強制します。

Apache（.htaccess）

<IfModule mod_headers.c>
  # 変更前: default-src * 'unsafe-inline'
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com; frame-src https://www.youtube-nocookie.com; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

nginx

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

IIS

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

Next.js（Vercel）

公式ガイドの第三者スクリプトの例のように、必要なドメインだけを追加します。

const cspHeader = `
  default-src 'self';
  script-src 'self' 'nonce-${nonce}' 'strict-dynamic' https://www.googletagmanager.com;
  connect-src 'self' https://www.google-analytics.com;
  img-src 'self' data: https://www.google-analytics.com;
`;

サイトを壊さないための注意点

• 外部の地図・動画・SNS埋め込み・翻訳ツール・アクセシビリティ支援ツールは、複数のドメインからリソースを読み込みます。各サービスの公式ドキュメントで、CSPに必要なドメインを確認してください。
• サブドメインのワイルドカード（*.example.com）は、そのドメイン配下に第三者がコンテンツを置ける場合（共有ホスティング、ユーザー投稿領域）は、実質的に広すぎる許可になります。
• img-src の data: は一般的ですが、script-src や object-src には data: を入れないでください。

設定後の確認方法

curl -sI https://www.example.lg.jp/ | grep -i '^content-security-policy' | tr -d '\r' | tr ';,' '\n\n' | grep -E "(^| )(\*|\*:\*|https?://\*|https?:|data:)( |$)"

tr -d '\r' は、ヘッダー行末の改行コード（CR）を取り除き、最後のディレクティブも検出できるようにするためです。表示された行が、全オリジン許可やスキーム全体の許可を含むディレクティブです。img-src の data: のように業務上許容しているものと、スクリプトへの許可を区別して確認してください。設定を変えたら、セキュリティAIチェッカーで再診断し、根拠欄にワイルドカードが表示されなくなったことを確認します。

よくある質問（FAQ）

参考資料

• W3C Content Security Policy Level 3
• OWASP WSTG-CONF-12 Test for Content Security Policy
• OWASP ASVS 5.0 V3 Web Frontend Security
• MDN HTTP Observatory CSPテスト実装（csp.js）
• Mozilla HTTP Observatory Scoring
• MDN CSP: script-src
• OWASP Content Security Policy Cheat Sheet
• Next.js「Content Security Policy」ガイド

「CSPの過剰なワイルドカード」と関連する診断項目

• CSPでHTTP配信元を許可していないhigh
• CSPのdefault-srcmedium
• クリックジャッキング対策high
• Content Security Policyhigh
• 外部スクリプト配信元を限定medium
• CSPでunsafe-inlineを許可していないhigh
• CSPでunsafe-evalを許可していないhigh
• CSP違反の報告先low