CSPでHTTP配信元を許可していないか？http:// と http: が危険な理由・混在コンテンツとの関係・修正方法

CSPでHTTP配信元を許可していないとは

CSPでHTTP配信元を許可していないとは、Content Security Policy（CSP）の配信元リストに、http://cdn.example.com のような平文HTTPのオリジンや、http:（HTTPなら何でも）というスキーム指定が残っていない状態のことです。

# 問題あり：画像をHTTPで読み込むことを許可している
Content-Security-Policy: default-src 'self'; img-src 'self' http://www.pref.example.lg.jp

CSPでHTTPの配信元を許可すると、そのリソースを暗号化されていない通信で読み込むことを許可していることになります。通信経路上の第三者（公衆Wi-Fiの運営者や攻撃者）は、平文のスクリプトや画像を書き換えられるため、HTTPSで守っているページに、改ざんされたコードが入り込む余地が生まれます。

セキュリティAIチェッカーのこの項目は、ヘッダーまたはmetaのCSPに、HTTPの配信元の指定が残っていないかを確認します。

「HTTP配信元」とは何か（CSPでの書き方と意味）

書き方ごとの意味

W3C CSP3 の scheme-part match では、http を指定したソースは https のURLにも一致します（安全側へのアップグレードを許すため）。逆は成り立ちません。したがって、http:// を https:// に書き換えても、正しくHTTPS配信されているリソースの読込は維持されます。

ブラウザの混在コンテンツ制御との関係

HTTPSページからHTTPのスクリプト・iframe等（能動的コンテンツ）を読み込むことは、W3C Mixed Content 仕様に基づき、ブラウザが既定でブロックします。画像・音声・動画（受動的コンテンツ）は、近年の主要ブラウザでは自動的にHTTPSへのアップグレードを試みます。つまり、CSPで http: を許可していても、HTTPSページではブラウザ側の制御で多くが止まります。

それでも、CSPにHTTP配信元が残っていることには次の問題があります。

• HTTPで閲覧された場合（HTTPS転送やHSTSがない環境、古い端末）には、何も守られません。
• 混在コンテンツの扱いはブラウザの種類・バージョンに依存します。CSPという明示的な宣言で禁止しておくのが確実です。
• 移行前の古い外部サービスへの依存が残っている兆候であり、配信元の棚卸しが不十分であることを示します。

Mozilla HTTP Observatory も、HTTPSサイトのCSPでHTTPからの読込を許可している場合を減点しています（画像・メディアのみで-10、それ以外で-20）。

upgrade-insecure-requests について

CSPの upgrade-insecure-requests を指定すると、ページ内のHTTPのURLへのリクエストを、ブラウザがHTTPSに書き換えて送ります。HTTPで書かれた古いリンクやCMS本文の画像URLを一括で救済できる便利な仕組みですが、書き換え先がHTTPSに対応していなければ読込は失敗します。配信元リストの http: を残す理由にはなりません。

HTML本文の src="http://…" などの混在コンテンツそのものは「Mixed Contentがない」、全オリジンやスクリプトへの https: の許可は「CSPの過剰なワイルドカード」で確認します。

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

取得対象

• トップページの最終応答の Content-Security-Policy ヘッダー（カンマ区切りの複数ポリシーを個別に分解）と、HTML内のmeta CSPを対象にします。
• ヘッダーとmetaの両方がある場合は、両方の全ポリシーを評価します。

検出条件

各ポリシーを ; でディレクティブに分割し、値を空白区切りのトークン（小文字化）として調べます。いずれかのディレクティブの値に、次のトークンがあれば「HTTP配信元を許可」とします。

• http:// で始まるソース式（ホストを指定したHTTP配信元）
• http: と完全に一致するトークン（スキーム全体の許可）

https://、https: は一致しません。次の2つは対象外です。

• report-uri・report-to の値（配信元の許可ではなく、報告先の指定のため）
• 'strict-dynamic' を含む script-src 系のディレクティブ（script-src・script-src-elem・script-src-attr）の値（ホスト・スキームの指定がブラウザに無視されるため）

判定条件

判定の考え方と限界

• ブラウザの混在コンテンツ制御で実害が抑えられる場合でも、CSPという宣言の段階でHTTPを許可していること自体を問題とし、×とします。
• ws:（暗号化なしのWebSocket）はこの項目の対象外です。WebSocketの暗号化は「WebSocketをWSSで暗号化」で評価します。
• meta側にだけ http:// が残っている場合も、ヘッダーのCSPと同じ基準で×になります。
• 報告先（report-uri）がHTTPのURLでも、この項目は×にしません。ただし、違反レポート（閲覧URL等を含む）が平文で送られるため、報告先もHTTPSにしてください。報告先の設定は「CSP違反の報告先」で確認します。
• HTML本文の src="http://…" などの混在コンテンツは、この項目ではなくHTML検査の項目で扱います。

自治体サイトでの判定例

CSPでHTTP配信元を許可しているとどんなリスクがあるか

• 通信経路での改ざん：公衆Wi-Fiなどで、平文で読み込まれたJavaScriptを攻撃者が書き換えると、ページ上で任意のコードが実行されます。入力フォームの内容の窃取や偽画面の表示につながります。
• 盗聴：HTTPで読み込むリソースのリクエストは、URLそのものに加え、Secure属性のないCookieや、条件によっては参照元の情報（Referer。ページ自体がHTTPの場合や、Referrer-Policyで送信を許可している場合）も平文で運ぶため、閲覧行動が第三者に知られます。
• HTTPで閲覧される経路：HSTSが未設定の環境では、最初のHTTPアクセスを攻撃者が中継（SSLストリップ）し、ページ全体をHTTPで見せることができます。この場合はページそのもの（CSPヘッダーを含む）が書き換えられうるため、CSPだけでは防げません。HTTPの配信元を許可するCSPは、HTTPでの閲覧を前提にした古い構成が残っている兆候でもあるため、HTTPS化・HSTSと併せて見直します。
• 防御の形骸化：サイト本体をHTTPS化・HSTS化していても、CSPがHTTPの読込を許していると、「安全な配信元だけ」という宣言の意味が弱まります。

CSPのHTTP配信元をHTTPSへ直す方法（Apache・nginx・IIS・Next.js）

修正の手順

1. CSPに含まれる http:// のオリジンと http: を一覧にします。
2. 各配信元がHTTPSに対応しているかを確認します（curl -sI https://配信元/パス）。
3. 対応していれば https:// に書き換えます。対応していなければ、ファイルを自組織のサーバーへ移す、HTTPS対応の代替サービスへ切り替えるなどで依存をなくします。
4. HTML本文側の http:// で始まる src・href もHTTPSへ書き換えます。移行期間中は upgrade-insecure-requests を併用できます。
5. report-uri の報告先もHTTPSにします（この項目の判定対象ではありませんが、レポートの平文送信を避けるためです）。

Apache（.htaccess）

<IfModule mod_headers.c>
  # 変更前: img-src 'self' http://www.pref.example.lg.jp
  Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https://www.pref.example.lg.jp; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; upgrade-insecure-requests"
</IfModule>

nginx

add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https://www.pref.example.lg.jp; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; upgrade-insecure-requests" always;

IIS

<add name="Content-Security-Policy" value="default-src 'self'; img-src 'self' data: https://www.pref.example.lg.jp; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; upgrade-insecure-requests" />

Next.js（Vercel）

next.config.js の headers() またはproxyで設定するCSPの文字列から http:// を除き、公式ガイドの例のように upgrade-insecure-requests を付けます。Vercelは既定でHTTPS配信のため、HTTPの配信元を許可する必要は通常ありません。

CMSを利用している場合

CMSの記事本文に、過去に貼り付けた http:// の画像・リンクが大量に残っていることがあります。データベースの一括置換はバックアップを取ってから行い、置換後に表示確認をします。WordPressでは、WP-CLIの search-replace（--dry-run で事前確認）が使えます。

外部サービスごとの確認ポイント

注意点

• upgrade-insecure-requests は、HTTPSに対応していない外部配信元の画像やスクリプトを「読み込めなくする」方向に働きます。導入前にHTTPS対応状況を確認してください。
• 混在コンテンツは、ブラウザの開発者ツールのコンソール（「Mixed Content」の警告）でも確認できます。

設定後の確認方法

curl -sI https://www.example.lg.jp/ | grep -i '^content-security-policy' | grep -oiE "(^|[ ;,])http:(//[^ ;,]*)?"

何も表示されなければ、HTTP配信元の指定はありません。report-uri の値や、'strict-dynamic' 付きの script-src 内の http: も表示されますが、これらはこの項目の判定対象外です。meta CSPはHTMLソースで別途確認します。

よくある質問（FAQ）

参考資料

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

「CSPでHTTP配信元を許可していない」と関連する診断項目

• Mixed Contentがないhigh
• CSPの過剰なワイルドカードhigh
• WebSocketをWSSで暗号化high
• CSP違反の報告先low
• Content Security Policyhigh
• CSPのdefault-srcmedium
• CSPでunsafe-inlineを許可していないhigh
• CSPでunsafe-evalを許可していないhigh