Chrome 56で警告されるHTTPの入力formは見た目より先にHTTPSの接続を確認する

Chrome 56は、HTTPでpasswordまたはcredit cardの入力欄を受けるpageを、安全でない接続として表示します。警告の文字やiconだけを消そうとするのではなく、入力画面から送信先までをHTTPSで扱えているかを確認してください。問い合わせformでも、氏名、連絡先、相談内容を受けるなら、通信経路を確認せずに公開を続ける理由はありません。

HTTPは、browserとserverの間で送る内容を暗号化しません。HTTPでpageを開いた場合、同じnetwork上の第三者が内容を見る、または途中の内容を書き換える可能性があります。Chromeが示す表示は、siteの印象だけの問題ではなく、入力した情報と表示した内容をどう送るかの問題です。

警告の対象とすべての入力欄を混同しない

Chromiumの2016年9月の案内では、2017年1月からのChrome 56で、HTTP page上のpasswordまたはcredit cardのform fieldを安全でないものとして表示すると説明しています。この時点で、HTTPの全pageが同じ表示になるわけではありません。まずはpasswordやcredit cardを受けるpageが対象です。

ただし、表示対象が限られるからといって、ほかの入力formをHTTPのまま後回しにしてよいとはいえません。問い合わせformには、氏名、email address、電話番号、事業上の相談内容が入ります。warningが出るかどうかと、利用者が安心して情報を送れるかどうかは別の判断です。

説明用の仮例として、住宅修繕の相談を受けるsiteを考えます。top pageはHTTPSで開くのに、問い合わせbuttonがHTTPのform pageへ進む場合があります。利用者はaddress barを細かく見ず、buttonを押して入力します。top pageだけをHTTPSにしても、入力pageと送信先がHTTPなら、最も確認すべき部分が残ります。

反対に、決済serviceの画面へ移動してcard情報を入力するsiteなら、自社siteにcard fieldがあるのか、外部serviceのURLへ移るのかを分けて確認します。外部serviceへ移る場合も、link先のURL、遷移する前に自社siteで伝える料金と条件、利用者がどこへ情報を渡すのかは確認が必要です。自社のserverへcard情報を受けないことは、確認が不要になることではありません。

HTTPS化はcertificateを入れる作業だけでは終わらない

HTTPSへ移す作業には、certificateを用意すること、web serverの設定を変えること、HTTPのURLからHTTPSのURLへ移すことが含まれます。どれか一つだけを終えても、利用者が常にHTTPSへ進むとは限りません。HTTPのURLが検索結果、bookmark、広告、email、紙の資料に残っていれば、利用者はそこから開きます。

確認する順序は、次のように分けます。

1. login、purchase、問い合わせ、資料請求など、入力を受けるURLを一覧にする。
2. 各URLをHTTPSで開き、certificateの警告や画像、script、CSSの読み込みエラーがないかを見る。
3. HTTPで同じURLを開き、HTTPSの対応するURLへ移るかを確かめる。
4. formを実際に送信し、送信先、完了page、受信内容を確認する。
5. menu、本文、広告のlanding page、email内のURLをHTTPSへそろえる。

ここで重要なのは、HTTPからHTTPSへ進むことと、HTTPSのpageが正しく使えることを分ける点です。HTTPのURLがHTTPSへ移っても、formを送ったあとにHTTPの完了pageが開く、画像が表示されずbuttonが押せない、受信先が別の管理者のまま、といった問題は残ります。redirectだけを確認して、formの動作を省かないでください。

WordPressを使うsiteでは、管理画面の設定、theme内の画像URL、pluginのform設定、広告用のlanding pageなどにHTTPが残ることがあります。設定画面のsite URLだけを変更して終わりにせず、公開画面でlinkをたどります。source codeにHTTPのURLが残っているかを調べる作業と、利用者が実際に送信できるかを確かめる作業も、別に必要です。

入力項目を減らすことと通信を守ることを分ける

HTTPSへ移すときは、formが集めている情報も見直します。通信を暗号化しても、不要な個人情報まで受け取ってよい理由にはなりません。最初の問い合わせで必要なのが名前、連絡先、相談内容だけなら、生年月日、勤務先、家族構成まで求める必要があるかを考えます。

入力項目を減らすことは、送信時の手間を減らすだけではありません。受け取る側が確認、保管、削除、引継ぎを行う情報も減ります。formを外部へ制作委託している場合は、制作会社がformを直せることと、受信dataを誰が見られるかを分けて確認します。domain、server、certificate、form service、受信mailboxの名義と管理者を、自社で把握しておきます。

たとえば、前の担当者が作ったformの受信先が個人のmailboxなら、HTTPSへ移しても引継ぎの問題は残ります。formの修正を頼む前に、送信先を誰が管理するか、退職や委託終了のあとに誰が確認できるかを決めます。通信の安全と、受け取った情報の管理責任は、つながっていますが同じ作業ではありません。

warningを見たら入力画面から確認する

Chromeのwarningを見たとき、最初にbrowserの表示を変えるpluginやCSSを探す必要はありません。入力するpageのURLを開き、address barがHTTPSか、certificateの警告がないか、送信後にどこへ進むかを確認します。次に、HTTPから開いた場合もHTTPSへ移るかを見ます。

小規模なsiteなら、確認対象は多くありません。login page、問い合わせpage、資料請求page、購入に進むpage、form送信後のpageを紙に書き出せば始められます。入力を受けるpageを一つずつ確認し、問題があればURL、画面、起きたことを残してserver管理者か制作担当者へ渡します。「HTTPSにしたい」だけでは、どのpageを直すべきか伝わりません。

最初の一手は、site内で利用者が文字を入力するpageを全て書き出し、HTTPで開くURLが残っていないかを見ることです。Chromeの表示を直すことを目的にせず、利用者が情報を渡す経路を確認します。