混合コンテンツの修正

Jo-el van Bergen
Jo-el van Bergen
X
Rachel Andrew

ウェブサイトで HTTPS をサポートすることは、攻撃からサイトとユーザーを保護するための重要なステップですが、混合コンテンツがあると、その保護が無効になる可能性があります。混合コンテンツとはで説明されているように、安全でない混合コンテンツはブラウザによってブロックされるようになります。

このガイドでは、既存の混合コンテンツの問題を修正し、新しい問題の発生を防ぐための手法とツールについて説明します。

サイトにアクセスして混合コンテンツを見つける

Google Chrome で HTTPS ページにアクセスすると、混在コンテンツがエラーや警告として JavaScript コンソールに表示されます。

混在コンテンツとはでは、さまざまな例を確認し、Chrome DevTools で問題がどのように報告されるかを確認できます。

パッシブな混合コンテンツの例では、次の警告が表示されます。ブラウザが https URL でコンテンツを見つけることができる場合、自動的にアップグレードされ、メッセージが表示されます。

混合コンテンツが検出され、アップグレードされたときに表示される警告を示す Chrome DevTools

アクティブな混合コンテンツはブロックされ、警告が表示されます。

アクティブな混合コンテンツがブロックされたときに表示される警告を示す Chrome DevTools

サイトの http:// URL に関してこのような警告が表示された場合は、サイトのソースで修正する必要があります。これらの URL のリストを、それらが見つかったページとともに作成しておくと、修正する際に役立ちます。

サイト内の混合コンテンツを見つける

ソースコードで直接、混在コンテンツを検索できます。ソースで http:// を検索し、HTTP URL 属性を含むタグを探します。アンカータグ（<a>）の href 属性に http:// が含まれていても、多くの場合、混合コンテンツの問題にはなりません。ただし、後述するいくつかの例外があります。

サイトがコンテンツ マネジメント システムを使用して公開されている場合、ページの公開時に安全でない URL へのリンクが挿入される可能性があります。たとえば、画像は相対パスではなく完全な URL で指定されている場合があります。CMS コンテンツ内でこれらのエラーを見つけて修正する必要があります。

混合コンテンツを修正する

サイトのソースで混合コンテンツが見つかったら、次の手順に沿って修正します。

リソース リクエストが HTTP から HTTPS に自動的にアップグレードされたというコンソール メッセージが表示された場合は、コード内のリソースの http:// URL を https:// に安全に変更できます。リソースが安全に利用できるかどうかを確認するには、ブラウザの URL バーで http:// を https:// に変更し、ブラウザタブで URL を開いてみます。

https:// 経由でリソースを利用できない場合は、次のいずれかのオプションを検討する必要があります。

  • 別のホストからリソースをインクルードします（利用可能な場合）。
  • 法律で許可されている場合は、コンテンツをダウンロードしてサイトで直接ホストします。
  • サイトからリソースを完全に除外する。

問題を修正したら、最初にエラーが見つかったページを表示して、エラーが表示されなくなったことを確認します。

標準以外のタグの使用に注意する

サイトで標準以外のタグが使用されていないか確認します。たとえば、アンカー（<a>）タグの URL は、ブラウザが新しいページに移動するため、混合コンテンツ エラーは発生しません。つまり、通常は修正する必要はありません。しかし、一部の画像ギャラリー スクリプトは <a> タグの機能をオーバーライドし、href 属性で指定された HTTP リソースをページ上のライトボックス表示に読み込むため、混合コンテンツの問題が発生します。

混合コンテンツを大規模に処理する

上記の手動の手順は、小規模なウェブサイトではうまく機能しますが、大規模なウェブサイトや、多数の個別の開発チームがあるサイトでは、読み込まれるすべてのコンテンツを追跡するのは困難です。このタスクを支援するために、コンテンツ セキュリティ ポリシーを使用して、混合コンテンツについて通知するようブラウザに指示し、ページが安全でないリソースを予期せず読み込まないようにすることができます。

コンテンツ セキュリティ ポリシー

コンテンツ セキュリティ ポリシー（CSP）は、混合コンテンツを大規模に管理するために使用できる多目的ブラウザ機能です。CSP レポート メカニズムを使用すると、サイト上の混合コンテンツを追跡し、混合コンテンツをアップグレードまたはブロックしてユーザーを保護する違反措置の適用プロセスに関するポリシーを提供できます。

これらの機能をページで有効にするには、サーバーから送信されるレスポンスに Content-Security-Policy ヘッダーまたは Content-Security-Policy-Report-Only ヘッダーを含めます。また、ページの <head> セクションで <meta> タグを使用して Content-Security-Policy を設定することもできます（Content-Security-Policy-Report-Only は設定できません）。

コンテンツ セキュリティ ポリシーを使用した混合コンテンツの検出

コンテンツ セキュリティ ポリシーを使用して、サイトの混合コンテンツのレポートを収集できます。この機能を有効にするには、サイトのレスポンス ヘッダーとして Content-Security-Policy-Report-Only ディレクティブを追加します。

レスポンス ヘッダー:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportingEndpoint

ユーザーがサイトのページにアクセスするたびに、ブラウザはコンテンツ セキュリティ ポリシーに違反する内容に関する JSON 形式のレポートを https://example.com/reportingEndpoint に送信します。この場合、サブリソースが HTTP 経由で読み込まれるたびにレポートが送信されます。これらのレポートには、ポリシー違反が発生したページの URL と、ポリシーに違反したサブリソースの URL が含まれます。これらのレポートをログに記録するようにレポート エンドポイントを構成すると、各ページにアクセスしなくても、サイト上の混合コンテンツを追跡できます。

これには次の 2 つの注意点があります。

  • ユーザーは、CSP ヘッダーを認識するブラウザでページにアクセスする必要があります。これは、ほとんどの最新のブラウザに当てはまります。
  • レポートは、ユーザーがアクセスしたページについてのみ取得されます。そのため、トラフィックが少ないページがある場合、サイト全体のレポートが作成されるまでに時間がかかることがあります。

詳細とエンドポイントの例については、コンテンツ セキュリティ ポリシーのガイドをご覧ください。

CSP を使用したレポートに代わる方法

サイトが Blogger などのプラットフォームでホストされている場合、ヘッダーを変更して CSP を追加できないことがあります。代わりに、ウェブサイト クローラーを使用して、サイト全体の問題を検出することをおすすめします。たとえば、HTTPSChecker や Mixed Content Scan などがあります。

安全でないリクエストのアップグレード

Browser Support

  • Chrome: 44.
  • Edge: 17.
  • Firefox: 48.
  • Safari: 10.1.

Source

ブラウザは、安全でないリクエストをアップグレードしてブロックするようになっています。 CSP ディレクティブを使用すると、これらのアセットの自動アップグレードまたはブロックを強制できます。

upgrade-insecure-requests CSP ディレクティブは、ネットワーク リクエストを行う前に安全でない URL をアップグレードするようブラウザに指示します。

たとえば、ページに <img src="https://example.com/image.jpg"> などの HTTP URL を含む画像タグが含まれている場合、

代わりに、ブラウザは https://example.com/image.jpg に対して安全なリクエストを送信するため、ユーザーは混合コンテンツから保護されます。

この動作を有効にするには、次のディレクティブを含む Content-Security-Policy ヘッダーを送信します。

Content-Security-Policy: upgrade-insecure-requests

または、<meta> 要素を使用して、同じディレクティブをドキュメントの <head> セクションにインラインで埋め込みます。

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

ブラウザの自動アップグレードと同様に、リソースが HTTPS 経由で利用できない場合、アップグレードされたリクエストは失敗し、リソースは読み込まれません。これにより、ページのセキュリティが維持されます。upgrade-insecure-requests ディレクティブは、ブラウザの自動アップグレードよりもさらに進んで、ブラウザが現在アップグレードしていないリクエストをアップグレードしようとします。

upgrade-insecure-requests ディレクティブは <iframe> ドキュメントにカスケードされ、ページ全体が保護されます。

前へ
混合コンテンツとは
次へ
ローカルでの開発に HTTPS を使用する場合