混合コンテンツチェッカー

アクティブとパッシブの混合コンテンツ

ブラウザはこの2種類を異なる方法で扱います。

• アクティブな混合コンテンツ（スクリプト、iframe、スタイルシート、XHR/fetch、ワーカー、WebSocket）。最近のブラウザでは完全にブロックされます。対象は <script>、<link rel="stylesheet">、<iframe>、fetch()、XMLHttpRequest、importScripts() など。
• パッシブな混合コンテンツ（画像、動画、音声のポスター）。読み込まれるものの警告が付きます、鍵マークが外れ、アドレスバーに警告が表示されます。対象は <img>、<audio>、<video>、フォームの action など。

なぜ重要なのか

• 信頼性。 壊れた鍵マークは、それに気づいたユーザーに「このサイトは安全でない」と明確に伝えます。
• 機能性。 アクティブなコンテンツがブロックされると、スクリプトが実行されず、スタイルシートも適用されないため、ページの表示が崩れます。
• SEO。 Google は HTTPS ページを優先します。HTTPS のシグナルが壊れていると、間接的に検索順位へ悪影響を及ぼします。
• コンプライアンス。 PCI DSS をはじめ多くのコンプライアンス基準は、決済ページに混合コンテンツのない HTTPS を求めています。

よくある原因

修正の戦略

1. プロトコル相対 URL（//cdn.example.com/a.js）。 現在のページのプロトコルで読み込まれます。ほとんどの CDN で安全ですが非推奨のため、明示的な https://... を優先してください。
2. ソースを書き換える。 テンプレートやコンテンツを https:// を使うよう更新します。正規表現 http://(?!localhost) でコードベースをスキャンしましょう。
3. Content Security Policy のアップグレード。 Content-Security-Policy: upgrade-insecure-requests は、HTTP アセットの URL を自動的に HTTPS へ書き換えるようブラウザに指示します。すべての URL を監査できないサイトに最適です。
4. <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> はそのインライン相当です。
5. HTTP のみのアセットをプロキシ経由で配信する。 上流に本当に HTTPS エンドポイントがない場合（現在ではまれ）、自サイトの HTTPS オリジンを経由させます。

チェッカーが検出する内容

• <img>、<script>、<link>、<iframe>、<video>、<audio>、<source> で参照されるすべての外部 URL。
• フォームの action 属性。
• <style> ブロック内のインライン CSS の url(...) 参照。
• JavaScript で挿入されたリソースはクロールしません。これらは実行時に追加されるため、ブラウザ側での監査が必要です（Chrome DevTools の「問題」パネルで検出できます）。