HTTPSで守られる通信とサイト全体の安全性を分ける

通信の保護を理解する

HTTPSはTLSを使って通信を暗号化します。途中での盗み見や改変への対策になりますが、送信先が受け取ったデータをどう扱うかまで保証するものではありません。

接続先の名前を確認する

鍵の形などブラウザの表示だけでなく、URLのホスト名を読みます。似たつづりの別ドメインもHTTPSを使えます。入力する予定の情報と、その送信先が正しいかを確認してください。

運営側はページ内の読込先も見る

自分のサイトでは、画像やスクリプトが古いHTTPのURLを参照していないか確認します。HTTPSページに保護されていないリソースが混ざる状態は混在コンテンツと呼ばれ、ブラウザが扱いを制限する場合があります。

警告を回避して完了にしない

証明書の期限、対象ドメイン、配信サービスの設定を確認します。警告を無視してアクセスできたことを公開確認の合格条件にしないでください。担当者に渡す場合は、警告文、対象URL、発生時刻を記録します。

1. HTTPSは、端末と送信先の間の通信を保護します。
2. 接続するホスト名が、意図した相手か確認します。
3. 自分のサイトでは、画像などの読み込み先も確認します。

保護される区間と情報の正しさを区別する

HTTPSで説明しているのは、通信を行う際の保護です。送信した文章の内容が正しいか、注文先が期待した事業者か、受け取った側が適切に保管するかという問いは、それぞれ別に残ります。HTTPSという表示を、サイトに関するあらゆる確認の代わりにしないようにします。

利用者としては、リンクの表示名だけでなく、実際に開いたURLのホスト名を確認します。運営者としては、利用者へ案内している名前で警告なく表示できるかを見ます。同じサイトに見える別名でも、設定がそろっているかは別の確認が必要です。

トップは開くのに画像が出ない例

公開後、トップページの文字は見えるが、一部の画像や機能が表示されない場面を考えます。まず対象ページと、読み込めない画像などのURLを分けて記録します。古いHTTPの参照が残っていないか、開発者向けの画面でエラーが出ていないかを確認します。

ただし、画像が出ないことを全て混在コンテンツの問題と決めつけません。ファイルの置き忘れやパスの誤りも調査対象です。観察した警告と実際の参照先を対応させ、原因が分かった箇所を修正します。変更後はトップだけでなく、その画像を使う下層ページも確認します。

公開確認の観点を整理する

最後の内容確認は、HTTPSの機能そのものとは別ですが、公開するサイトには必要な作業です。問い合わせフォームがあるなら、入力する情報の送信先も実装と照合します。警告を回避する操作を通常手順にせず、必要な条件を直してから確認します。担当者へは、端末の画面写真だけでなく、対象URLと警告文が分かる記録を渡します。

参考リンク

• MDN: HTTPS
• MDN: Mixed content