ウェブサイトで HTTPS をサポートすることは、サイトとユーザーを攻撃から保護するための重要なステップですが、混合コンテンツによってこの保護が無意味になる可能性があります。混合コンテンツとはで説明されているように、安全でない混合コンテンツはますますブラウザによってブロックされるようになります。
このガイドでは、既存の混合コンテンツの問題を修正し、新しい問題が発生しないようにするための手法とツールについて説明します。
サイトにアクセスして混合コンテンツを見つける
Google Chrome で HTTPS ページにアクセスすると、ブラウザの JavaScript コンソールに混合コンテンツがエラーと警告として示されます。
混合コンテンツとはで、さまざまな例を確認し、Chrome DevTools で問題がどのように報告されるかを確認できます。
パッシブな混合コンテンツの例では、次の警告が表示されます。ブラウザが https
の URL でコンテンツを検出できた場合は、自動的にアップグレードされ、メッセージが表示されます。
アクティブな混合コンテンツがブロックされ、警告が表示されます。
サイトの 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 など、ウェブサイト クローラを使用してサイトの問題を見つける方法があります。
安全でないリクエストのアップグレード
ブラウザは、安全でないリクエストをアップグレードしてブロックし始めています。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>
ドキュメントに適用されるため、ページ全体が保護されます。