混在コンテンツ

ウェブページ内の混在コンテンツは、「アップグレード可能コンテンツ」と「ブロック可能コンテンツ」の 2 つのカテゴリーに分けられます。 ブラウザーは自動的に、アップグレード可能コンテンツのリクエストを HTTP から HTTPS にアップグレードし、ブロック可能コンテンツのリクエストをブロックします。

この手法により、保護されたコンテキストにあるすべてのコンテンツは、保護されたチャネル経由で読み込まれるか、ブロックされることが保証されます。これは、保護されたコンテンツと保護されていないコンテンツが混在する状態よりもユーザーにとって安全であり、保護されていないコンテンツをすべてブロックしてウェブページがまったく表示されなくなるよりも混乱が少ないといえます。

「アップグレード可能コンテンツ」を構成する一連のリソース型は、「オプションでブロック可能な」混在コンテンツの一覧から選択されたものです。 今後、新しいファイル形式はすべてブロック可能なコンテンツとして定義され、一部のアップグレード可能コンテンツも将来的にブロック可能になることが予想されます。

アップグレード可能なコンテンツリクエストは、オリジンのスキームを http から https に変更することで、安全ではないリクエストが自動的に保護されたリクエストにアップグレードされます。 リモートサーバーは、リソースを返すか、または見つからなかったことを示すステータスコードを返します。

このカテゴリーのリソース型は、リクエストをブロックするとウェブの重要な部分が機能しなくなる可能性があるものです。 これらは現在、以前「オプションでブロック可能」であった混在コンテンツ型に該当します。なぜなら、これらのコンテンツ型は一部のウェブサイトで現在も使用されているからです。

次の要素はアップグレード可能です（URL ホストを IP アドレスとして指定する場合を除きます。次の節を参照してください）。

• <img> でオリジンを src 属性で設定するもの、SVG 文書を含む（ただし、 srcset や <picture> でリソースを設定する場合は含まない）。
• CSS の画像要素。 background-image、border-image、など。
• <audio> でオリジンを src 属性で設定するもの。
• <video> でオリジンを src 属性で設定するもの。
• <source> で動画またはオリジンリソースを設定するもの。

ブロック可能なコンテンツは、「アップグレードできないすべての混在コンテンツ」と定義されています。

これには、次の要素から生じる HTTP リクエストが含まれます（このリストは網羅的なものではありません）。

• <script> でオリジンを src 属性で設定するもの。
• <link> でオリジンを href 属性で設定するもの（スタイルシートを含む）。
• <iframe> でオリジンを src 属性で設定するもの。
• fetch() リクエスト
• XMLHttpRequest リクエスト
• <url> 値を用いる CSS すべて （@font-face、cursor、background-image など）
• <object> (data 属性)
• Navigator.sendBeacon (url 属性)
• <img> でオリジンを srcset または <picture> で指定するもの。
• ウェブフォント

URLのホストがドメイン名ではなくIPアドレスの場合、アップグレードされるはずの、混在コンテンツのリクエストはブロックされます。 つまり、 <img src="http://example.com/image.png"> はアップグレードされますが、 <img src="http://93.184.215.14/image.png"> はブロックされます。

混在コンテンツのリクエストとは、保護されたコンテキストにおける保護されていないリソースのリクエストです。

次の例は、保護されたコンテンツ、保護されていないコンテンツ、および混在コンテンツのリクエストを説明しています。

• http://insecure.com が http://also.insecure.com を読み込む — どちらのオリジンも安全ではないため、混在コンテンツのリクエストではありません。
• https://secure.com が http://insecure.com を読み込む — これは混在コンテンツのリクエストです。安全ではないリソース http://insecure.com が保護されたコンテキスト https://secure.com に読み込まれるからです。
• http://insecure.com が https://secure.com を <iframe> に読み込み、さらに http://also.insecure.com を読み込む — https://secure.com を http://insecure.com に読み込むことは、混在コンテンツのリクエストではありません（保護されたコンテキストを保護されていないコンテキストに読み込むことに対する制限はありません）。 しかし、 http://also.insecure.com を保護されたフレーム https://secure.com に読み込むことは、混在コンテンツのリクエストです。
• https://secure.com が data: URL をフレーム化し、http://insecure.com を読み込む — これは混在コンテンツのリクエストです。 https://secure.com （したがって、data:）は安全に読み込まれ、 http://insecure.com は安全ではないからです。

混在コンテキストのリクエストは、プラグインやワーカーなどの保護されたコンテキストからも行われ、同じ方法でアップグレード/ブロックされます。

ただし、保護されたコンテキストからのリクエストで、保護されていない最上位の閲覧コンテキストをターゲットとするナビゲーションリクエストは、リクエストのオリジンに関係なく、新しいコンテキストを作成し、そのコンテキストが保護されるかされないかになるので、混在コンテンツとは見なされないことに注意してください。

ローカルリソースは、 HTTPS のオリジンと同様に、保護されたオリジンから取得されたものと見なされます。 これには file: URL、およびループバックアドレス（http://127.0.0.1/ や http://localhost/ など）からアクセスするコンテンツが含まれます。

これらのファイルは保護されたコンテキストから読み込むことができ、保護されたコンテキストのままになります。 しかし、ローカルファイルが http: 経由で保護されていないリソースを読み込んだ場合、それは混在コンテンツのリクエストとなります。

ローカルコンテンツの読み込みに対応しているかどうかは、ブラウザーの互換性の節で調べることができます。

混在ダウンロードとは、保護されたコンテキストから保護されていない接続を介してリソースをダウンロードすることです。 これらは、混在コンテンツと同じ理由で問題となります。コンテンツは攻撃者によって介入されたり、変更されたりする可能性があり、ユーザーには保護されたサイトでこのようなことが現れる可能性があることが分かりにくくなります。

例えば、次のコードは、保護されていないオリジン http://example.com/ にあるページをダウンロードするために使用できる <a> 要素を定義しています。 このコードが HTTPS で配信されるページにある場合、リンクを保存すると、混在ダウンロードが発生します。

<a href="http://example.com/" download>ダウンロード</a>

ブラウザーは混在ダウンロードをブロックすることが望ましく、保護されたサイトには含めないようにすべきです。

開発者コンソールには、混在コンテンツがアップグレードまたはブロックされた際に、警告が表示されます。 これにより、ウェブサイト上の混在コンテンツをデバッグし、修正することができます。

次のスクリーンショットは、 Firefox で画がをアップグレードされる際にコンソールに表示される警告を示しています（Chrome にも同様の警告があります）。

「オプションでブロック可能」なコンテンツを表示するバージョンのブラウザーでは、コンソール警告とともに、表示コンテンツに混在コンテンツがあることを示すアイコンが使用されます。 次のスクリーンショットは、 Firefox がアップグレード可能な混在コンテンツに対応し始めたことを示すアイコンとコンソール警告を示しています。

混在コンテンツに関する課題を避けるための最善の策は、すべてのコンテンツを HTTPS で提供することです。

• ドメイン内のすべてのコンテンツを HTTPS で提供する。

• ダウンロードする場合を含め、ドメインでホストされているリソースへの参照をすべて相対リンクまたは HTTPS リンクに変更する。

• 他のサイトのリソースを使用している場合、可能であれば HTTPS バージョンを使用する。

  ほとんどのサイトでは、共有リソースの HTTPS バージョンが指定されています。 最も簡単な手法は、 http:// のリンクをすべて https:// に置き換え、 LinkChecker などのツールを使用して、リンクがすべて正しく動作することを確認することです。

サイトに混在コンテンツがないことを確認する方法はいくつもあります。例えば以下のようなものです。

• サイトを巡回し、ブラウザーの開発者コンソールで混在コンテンツの警告がないか調べます。
• ブラウザー上のすべての混在コンテンツを無効にし、ページが期待通りに動作することを検査します。 これは Safari のでは既定の動作ですが、ほとんどのブラウザーは、すべての混在コンテンツをブロックする何らかの仕組みに対応しています（互換性データを参照）。
• HTTPSChecker のようなデスクトップベースのウェブクローラー、または mcdetect のような CLI ツールを使用して、ウェブサイトを再帰的に調べ、保護されていないコンテンツへのリンクを探します。
• Mixed Content Checker のようなオンラインツールを使用して、サイトを調べます。

• CSP: upgrade-insecure-requests ブロック可能な混在コンテンツを含め、すべてのリクエストを HTTPS へアップグレードする