HTTPS pageのmixed contentは画像だけで済ませず読み込むURLを種類ごとに確認する

HTTPSへ切り替えたpageで、画像、CSS、JavaScript、iframeなどをHTTPのURLから読み込むと、page全体の通信と読み込む部品の通信がそろいません。この状態をmixed contentと呼びます。証明書を入れてtop pageがHTTPSで開けても、それだけでは確認になりません。実際に表示するpageを開き、何をどのURLから読むかを種類ごとに確かめます。

W3CのMixed Contentは、暗号化され認証されたdocumentの中で、暗号化または認証されない接続からresourceを取得する状況を扱っています。安全なpageへHTTPのresourceを混ぜると、通信の途中で内容を書き換えられる余地が残ります。見た目の鍵の表示だけでなく、form、script、画像、外部の埋込みまでそろえる必要があります。

HTTPSで開けることとresourceがHTTPSであることは別である

サイトをHTTPSへ移す作業では、まずpageのURLをHTTPからHTTPSへ替えます。しかしHTMLの中には、別のURLが多く残ります。logoの画像、CSS file、JavaScript file、web font、広告やmapのiframe、PDFへのlink、formの送信先などです。pageの先頭URLだけを替えても、これらがHTTPのままなら、通信の条件は一つになりません。

説明用の仮例として、会社案内をhttps://example.jp/about/で公開したとします。本文の写真をhttp://example.jp/images/company.jpgから読み、問い合わせformの送信先をhttp://example.jp/contact/send/へ向けているなら、画面のURLだけはHTTPSでも、必要なresourceと送信先がHTTPです。画像が表示されているから問題がない、formが送信できたから安全だ、と判断しません。

特にJavaScriptとCSSは、表示の部品ではなくpageの動作と内容に関わります。HTTPから読んだJavaScriptが途中で差し替えられれば、入力内容を扱うformや表示を変える処理へ影響します。HTTPのCSSも、読者が見ている案内の表示を変えます。画像だけを直してconsoleの警告が消えないときは、templateやpluginが出すCSS、JavaScript、iframeを分けて探します。

外部serviceを使う場合も同じです。動画、map、予約form、アクセス解析、fontを外部のURLから読み込むなら、そのserviceがHTTPSのURLを提供しているかを確認します。URLを自分で直せないserviceなら、単にhttps://へ書き換えて公開しません。正しい埋込み方法、対象browserでの表示、service側の利用条件を確認します。外部の部品を置く判断と、通信を安全にする責任を別の人へ丸ごと渡さないためです。

直す対象は画面に見えるものから探さない

mixed contentの原因は、画面に見える画像だけとは限りません。headerやfooterに共通で置くscript、管理画面の設定に保存したURL、CSS fileの中に書いた背景画像、古い記事本文の画像URLにも残ります。top pageだけを直しても、個別記事、固定page、検索結果、404 pageで同じ部品を読む場合があります。

確認は、公開中のURLをいくつか選んで行います。top page、問い合わせpage、記事page、画像を多く使うpage、外部serviceを埋め込んだpageを開きます。それぞれでbrowserの開発者向け画面を使い、HTTPで読もうとしたresourceの種類とURLを記録します。警告文を消すことだけを目的にせず、どのtemplateまたは本文がそのURLを出したかまでたどります。

この表は確認の順番を決めるためのものです。すべてのpageに同じ部品があるとは限りません。問い合わせpageだけに外部formがある、記事だけに古い画像URLが残る、といった違いを先に分けます。一つの修正で全URLが直ったと推測せず、原因の場所に応じて確認対象を増やします。

WordPressでは、site addressをHTTPSへ替えた後にも、本文やcustom fieldに保存した絶対URLが残ることがあります。theme fileだけを検索して終えず、実際の公開画面と投稿本文の両方を確かめます。databaseを一括で置換する作業は、URL以外の文字列や保存形式まで変えるおそれがあります。対象、backup、戻す手順を決めずに実行しません。まず、どのcontent typeのどのURLにHTTPが残っているかを数えます。

URLを直す前にresourceの所有者を分ける

HTTPのURLを見つけても、直し方は一つではありません。自分のserverにある画像なら、HTTPSで読めるURLへ直します。外部のscriptなら、その提供元が示すHTTPSの埋込みURLを使えるか確認します。提供元がHTTPSを用意していない場合は、URLの先頭だけを替えて動作するとは限りません。その部品を残す理由と、代わりの方法を検討します。

たとえば古い画像が自社serverにあり、HTTPSのpageからHTTPで読まれているなら、まず同じ画像をHTTPSのURLで直接開けるかを確かめます。証明書の対象外のhostへ置かれているなら、URLだけでなく画像の置き場所か証明書の設定を直す必要があります。外部の写真serviceなら、利用者のbrowserから外部serviceへ直接接続すること、そのserviceがURLを管理することを記録します。

相対URLを使えば常に解決するわけでもありません。/images/company.jpgのようなURLは同じhostのHTTPS pageではHTTPSとして読まれますが、別のhostに画像を置く構成には使えません。protocol relative URLとして//example.jp/images/company.jpgと書く方法は、開いたpageのschemeに従います。HTTP pageからも使う期間がある場合、意図せずHTTPで読む可能性があります。HTTPSへ統一する方針なら、どのhostのどのresourceかを明示したHTTPSのURLを使う方が、確認しやすい場合があります。

制作会社へ直してもらうなら、「mixed contentを直す」とだけ伝えません。警告が出る公開URL、HTTPで読まれるresourceのURL、resourceの種類、所有者、修正後に確認する画面を渡します。作業後には、直したtemplate、記事本文、設定値を分けて受け取ります。次に画像や計測scriptを替える担当者が、何をHTTPSで登録すべきか分からなければ、同じ問題が戻るためです。

formと外部linkは表示とは別に確かめる

問い合わせformでは、入力欄がHTTPSのpageにあることだけで終えません。actionの送信先、送信時に読むscript、完了page、受信先を一続きで見ます。送信先だけHTTPなら、読者が入力した情報を安全なpageから出す意味が薄れます。テスト送信が可能なら、個人情報を使わないtest dataで入力から完了まで進み、受信する側が必要な内容を確認できるかを確かめます。

外部linkはmixed contentそのものとは別です。HTTPSのpageから外部siteへ通常のlinkを置くことと、そのsiteのscriptやiframeをpage内へ読み込むことは同じではありません。前者は読者がlinkを選んだあとに別のpageへ移動します。後者は、読者が現在開いているpageの中で外部resourceを読みます。外部へ案内するlinkまで全て削除する必要はありませんが、埋込みresourceは取得URLと表示内容を別に確認します。

SSL証明書の更新、HTTPからHTTPSへの301転送、canonical、内部link、サイトマップも移行には必要です。ただし、これらを一度に直すと、表示の問題、URLの問題、検索への案内の問題が混ざります。mixed contentを直す作業では、まずHTTPSのpageがHTTPのresourceを読まない状態を作ります。その後にURLの統一と検索向けの確認を進めれば、問題が起きた場所を分けて追えます。

公開後は代表pageだけで終えず更新経路を確認する

初回の確認でmixed contentがなくても、更新時にHTTPのURLを貼れば再び起こります。記事を書く人が画像を貼る、外部の予約formを差し替える、計測用scriptを追加する、といった作業の入口でHTTPSのURLを選べるようにします。運用の規則は、長い手順書より、更新画面で確認できる形にした方が守りやすくなります。

たとえば、画像を登録する担当者には、画像URLを貼る前にHTTPSで直接開けるかを確かめてもらいます。外部serviceを追加する担当者には、提供元の埋込みコードをそのまま貼る前に、HTTPSのURLか、どのpageへ入れるかを確認してもらいます。制作担当者には、共通templateへ外部scriptを加える場合、取得URLと用途を残してもらいます。誰が何を更新するかを分ければ、警告が出たときに確認する場所も分かれます。

確認の対象は、更新したpageだけではありません。headerやfooterを変えたなら、個別記事と固定pageにも同じresourceが出ます。外部formを変えたなら、送信後の完了pageまで見ます。画像URLを置換したなら、古い記事や一覧のthumbnailにも残っていないかを見ます。公開時に一度直す作業と、更新後に戻らないようにする作業を分けます。

最初の一手は、HTTPSで開く代表pageを五つ選び、HTTPで読み込むresourceがないかを種類ごとに記録することです。見つけたURLは画像、CSS、JavaScript、iframe、formに分け、所有者と出力する場所を確かめてから直します。