混合コンテンツの修正

ウェブサイトで 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-PolicyContent-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

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

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

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

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

CSP による報告に代わる方法

サイトが Blogger などのプラットフォームでホストされている場合は、ヘッダーの変更や CSP の追加ができない場合があります。代わりに、HTTPSChecker混合コンテンツ スキャンなど、ウェブサイト クローラを使用してサイト全体の問題を検出することもできます。

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

対応ブラウザ

  • 44
  • 17
  • 48
  • 10.1

ソース

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

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

たとえば、ページに「<img src="http://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> ドキュメントにカスケードされ、ページ全体が保護されます。