なぜ危ないのか
HTTPSページ上でhttp://のリソースを読み込むと、ブラウザはその通信を暗号化されていない平文で行います。公共Wi-Fiや中間者攻撃の環境では、このhttp通信が傍受・改ざんされるリスクがあります。特にJavaScriptファイルがhttp経由で読み込まれている場合、攻撃者がスクリプト内容をすり替えてページ全体を乗っ取ることが理論上可能です。
AIはサンプルコードをトレーニングデータから引用するため、古いHTTPエンドポイントを参照するコードスニペットを混入させることがあります。生成時点ではローカルで動作していても、HTTPSホスティングに移行した瞬間にブラウザのMixed Contentブロック機能が働き、リソースが読み込まれなくなります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
HTMLファイルを開いてターミナルで `grep -n 'http://' index.html` を実行します。`href`・`src`・`action`・`data-url`など属性名を問わず全件ヒットするため、出力行番号を元にエディタで該当箇所を修正します。プロトコルを省略した `//example.com/` 形式は相対プロトコルなので混在にはなりませんが、意図した通信先かどうかは別途確認が必要です。
Chromeの開発者ツールを開き「コンソール」タブを表示した状態でページをリロードすると、Mixed Contentの警告が `Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'` という形式で一覧表示されます。警告レベル（Warnings）とエラーレベル（Errors）で表示が分かれており、Errorsに表示されるリソースはブラウザが自動でブロックしています。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
修正方法は原則として`http://`を`https://`に書き換えるだけです。ただし参照先のサーバーがHTTPSに対応していない場合は、同等のHTTPS対応CDNやnpmパッケージの自己ホスト版に差し替える必要があります。例えば `http://code.jquery.com/jquery-1.12.0.min.js` は `https://code.jquery.com/jquery-3.7.1.min.js` に置き換えてバージョンも最新化することを推奨します。
Cloudflareのプロキシを経由して配信する場合、「自動HTTPS書き換え（Automatic HTTPS Rewrites）」機能を有効にすると、HTML内のhttp://リソースURLをサーバー側で自動的にhttps://に変換して配信できます。応急処置として有効ですが、参照先が実際にHTTPS非対応のときはブロックが発生するため、根本的な修正と併用してください。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
AIへのプロンプトに「外部リソースはすべてhttps://で記述すること」という制約を加えます。さらに「外部CDNに依存するライブラリは使わず、インラインで実装するか、ファイル内にコピーすること」とすれば、Mixed Content自体を根本から防げます。
CIに `grep -r 'src=["\']http://' .` と `grep -r 'href=["\']http://' .` を含むスクリプトを追加し、http://リソース参照が含まれるコミットをブロックする仕組みを作ります。GitHub Actionsなら5行程度のyamlで設定でき、レビュー担当者の目視負担を大幅に減らせます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
ブラウザがhttp://リソースを自動でhttpsに書き換えてくれることはありますか？
Chrome 94以降はアップグレード可能なMixed Contentを自動でhttpsに昇格させます。ただし昇格に失敗するとリソースがブロックされるため、ソース側でhttpsに修正するのが確実です。
CSSファイル内で参照している画像がhttp://の場合も問題になりますか？
なります。CSSのurl()でhttp://の画像を参照している場合もMixed Contentとして扱われ、対応ブラウザではブロックまたは警告が表示されます。CSSファイルもgrepの対象に含めてください。
ローカルのfile://プロトコルで開いたときは警告が出ないのに公開後に問題になりました。なぜですか？
file://はHTTPSでもHTTPでもないためMixed Contentの制限が適用されません。公開前にlocalhostのHTTPSサーバーか本番に近い環境で必ず動作確認してください。