混在コンテンツの修正
ウェブサイトでHTTPSをサポートすることは、サイトとユーザーを攻撃から保護するための重要なステップですが、コンテンツが混在していると、その保護の効果が損なわれてしまいます。What is mixed content? (混合コンテンツとは?)でも説明があるように、安全でない混在コンテンツはブラウザによってブロックされます。
このガイドでは、混在コンテンツに関する既存の問題を修正し、新しい問題の発生を防ぐための手法とツールをご紹介します。
自身のサイトにアクセスして混在コンテンツを見つける #
Google ChromeでHTTPSのページにアクセスすると、ブラウザは、混在コンテンツある場合、JavaScriptコンソール内でそれをエラーおよび警告として表示します。
What is mixed content? (混在コンテンツとは?)では、数多くの例に加え、Chrome DevToolsで問題が報告される仕組みを紹介しています。
パッシブ混在コンテンツの例では、次のような警告が表示されます。ブラウザは、https
URLでコンテンツを見つけることができれば、それを自動的に更新してからメッセージを表示します。

アクティブな混在コンテンツはブロックされ、以下のような警告が表示されます。

サイトのhttp://
URLについて、こうした警告が見つかった場合は、サイトのソースで修正する必要があります。こうしたURLをそれぞれが見つかったページと一緒にリストアップしておけば、修正するときに便利です。
サイト内の混在コンテンツを見つける #
混在コンテンツは、ソースコードの中で直接検索できます。ソースでhttp://
を検索し、HTTP URL属性を含むタグを探します。アンカータグ (<a>
)のhref
にhttp://
があっても、それは混在コンテンツの問題ではない場合がしばしばあります。注目すべき例外がいくつかありますが、それらについては後ほど解説します。
サイトがコンテンツ管理システムを使って公開されている場合は、ページが公開された時に安全でないURLへのリンクが挿入されている可能性があります。たとえば、画像に、相対パスではなく、完全なURLが含まれる場合などがあります。これは、CMSコンテンツ内で見つけて修正する必要があります。
混在コンテンツの修正 #
サイトのソースに混在コンテンツを見つけたら、次のステップで修正します。
リソースリクエストがHTTPからHTTPSに自動的に更新されたというコンソールメッセージが表示された場合は、コード内のリソースのhttp://
を安全にhttps://
に変更できます。また、ブラウザのURLバーのhttp://
をhttps://
に変更し、そのURLをブラウザのタブで開けば、リソースが利用できるかどうかを安全に確認できます。
リソースがhttps://
経由で利用できない場合は、次のいずれかのオプションを検討することをおすすめします。
- 別のホストのリソースを含める (利用可能な場合)。
- コンテンツをダウンロードして、自分のサイトで直接ホスティングする (法的に許可されている場合)。
- サイトからリソースを完全に除外する。
問題を修正したら、最初にエラーを見つけたページを表示して、エラーが表示されなくなったことを確認します。
タグの非標準的な使い方に注意する #
サイトで非標準的な使われ方をしているタグに注意してください。たとえば、アンカー (<a>
) タグのURLは、ブラウザを新しいページに移動させるものであるため、混在コンテンツのエラーにはなりません。つまり、通常なら、これを修正する必要はありません。ただし、一部の画像ギャラリースクリプトは、<a>
タグの機能をオーバーライドし、href
属性が指定するHTTPリソースをページのライトボックスのディスプレイに読み込んでしまうため、混在コンテンツの問題を引き起こします。
混在コンテンツを広範に処理する #
小規模なウェブサイトであれば、こうした手動による手順でも事足りるでしょう。ただし、サイトが大規模なものであったり、多数の開発チームが関与するものであれば、そのサイトに読み込まれるすべてのコンテンツを追跡するのは困難になります。この場合、コンテンツセキュリティポリシーを使って、ブラウザに混在コンテンツについて通知するよう指示を出せば、安全でないリソースが予期せぬかたちでページに読み込まれることを確実に防げます。
コンテンツセキュリティポリシー #
Content security policy (コンテンツセキュリティポリシー) (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ヘッダーを理解できるブラウザーでページにアクセスする必要があります。最新のブラウザの多くについて言えることです。
- レポートは、ユーザーがアクセスしたページの分しか取得できません。トラフィックの少ないページがある場合は、サイト全体のレポートを取得するまでに少し時間がかかるかもしれません。
Content security policy (コンテンツセキュリティポリシー) ガイドに詳しい情報とエンドポイントの例を記載しています。
CSPを使用したレポートの代替手段 #
サイトがBloggerなどのプラットフォームでホストされている場合は、ヘッダーを変更したりCSPを追加したりするためのアクセス権を持っていない場合があります。代わりに、実行可能な代案として、HTTPSCheckerやMixed Content Scanといったウェブサイトクローラーを用いて、サイト全体で問題を探るということができます。
安全でないリクエストの更新 #
ブラウザは、安全でないリクエストを更新したり、ブロックしたりするようになりつつあります。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>
ドキュメントにカスケードするため、ページ全体の安全が保証されます。
すべての混在コンテンツをブロックする #
ユーザーを保護するための代替の選択肢に、block-all-mixed-content
CSPディレクティブがあります。このディレクティブは、ブラウザに混在コンテンツを決して読み込まないという指示を出します。アクティブとパッシブの両方を含めたすべての混在コンテンツに対するリソース要求がブロックされます。この選択肢も、<iframe>
ドキュメントにカスケードしますので、ページには混在コンテンツが一切含まれないことが保証されます。
次のディレクティブを指定して、Content-Security-Policy
ヘッダーを送信すれば、ページは自らこの動作にオプトインできるようになります。
Content-Security-Policy: block-all-mixed-content
もしくは、<meta>
要素を使って、同じディレクティブをドキュメントの<head>
セクションに埋め込みます。
<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">