デジタルマーケティングTips

この冬、Chrome 80・81が出るまでにWebサイト担当者が対応しておくこと

各種Webブラウザは新機能対応やセキュリティ強化のための仕様変更を随時続けていますが、2020年2月公開予定のChrome 80、3月公開予定のChrome 81では、対策を要する大型仕様変更が予定されています。表示の不具合等を防ぐため、未対応の場合は至急対策をしていくのがおすすめです。

もくじ

[A]サードパーティCookie取扱条件の制限強化への対応

概要

Chrome 80(2020年2月公開予定)以降、サードパーティCookieを取り扱う際には、SameSite=None属性およびSecure属性をWebシステム側で個別に付与する必要があります。

これに伴い、古い埋め込みタグの更新、サイト全体のhttps化などの対策が必要になる場合があります。

対応を行わない場合、アクセス解析やソーシャルプラグイン等の動作に支障が出るおそれがあります。

解説

Webサイトでは、アクセス解析タグ・広告計測タグや、ツイート/いいねボタンに代表されるソーシャルプラグイン等を挿入する際、自サイト以外が発行するCookie、すなわち「サードパーティCookie」をブラウザにセットすることがあります。

サードパーティCookieはサイト(ドメイン)をまたいだアクセスの計測などで便利に使われる一方、クロスサイトリクエストフォージェリ(CSRF)等の不正アクセスに悪用される危険性があります。この対策として、Chrome 51以降では、開発者が自分で発行したCookieのアクセス先を制限する'SameSite'属性が、3段階で付与できるようになりました。

  • SameSite=Strict … 最も制限が厳しい。サードパーティCookieを遮断し、ファーストパーティCookie(自サイト発行Cookie)のみ許可
  • SameSite=Lax … ゆるく制限。トップレベルナビゲーション(URL変更を伴う遷移)など一部の条件でのみサードパーティCookieを許可
  • SameSite=None … 制限なし。サードパーティCookieをこれまで通りすべて許可

サードパーティCookieにSameSite属性指定が何もない場合、これまでChromeは動作互換性確保のため'SameSite=None'と同様の扱いとして自由なアクセスを許可してきました。が、ついにChrome 80から無指定時のアクセス制限が'SameSite=Lax'に引き上げられます。これにより、各種埋め込みタグなどのサードパーティCookieは、各提供元が'SameSite=None'設定を明示的に指定しないと、埋め込み先のサイトで機能しなくなります。

さらに、Chrome 80では同時に「サードパーティCookieに'SameSite=None'属性をつける場合は同時に'Secure'(暗号化通信)属性も付与しなければならない」という制限も加わります。これは事実上「https(暗号化通信)サイトでなければサードパーティCookieは動作しなくなる≒埋め込みタグ等の動作に支障が出る」ことを意味します。

対策

Webサイト管理者が行うべき対策は大きく2つです。

  • 埋め込みタグ等の対応…他社埋め込みタグを自サイトに入れている場合、基本的には埋め込みタグ提供元の対応を待つことになります。古い世代の埋め込みタグは、提供元の対応によっては最新版への置き換えが必要な可能性があり、それぞれの対応状況を随時チェックする必要があります。
    対応が必要なCookieを確認したい場合は、Chromeで[F12]キーから開発者メニューを開き、右上の黄色い△の注意アイコンをクリックすると、画面下の注意欄に、対応が必要なCookieが一覧表示されます。
  • サイト全体の暗号化通信(https、常時SSL)化…サイト全体がまだ暗号化通信非対応(http://~)の場合、全体を暗号化通信対応(https://~)させる必要があります。

参考サイト

[B]暗号化(https)・非暗号化(http)混合コンテンツの制限強化への対応

概要

Chrome 80以降、httpsのページからhttpのコンテンツを呼び出す場合、呼び出すURLを自動的に(強制的に)http→httpsに置き換えて呼び出す変更が行われます。

これに伴い、サーバーのhttp用領域に残存しているコンテンツの移動、URLの置き換えなどが必要になる場合があります。

対応を行わない場合、コンテンツの読み込み失敗、サイトの表示崩れ・機能不全等が発生するおそれがあります。

解説

SSL/TLSによるWebの暗号化通信(https://~)は、セキュリティに優れるものの、かつては処理速度等の都合により、登録フォームなどサイトの一部のみに留められていました。これをWebサイト全体に適用する、いわゆる「常時SSL化」をGoogle等が推進したことで、現在では多くのサイトがコンテンツ全体をhttps://~のURLに移行させています。

ところが、移行処理が不十分だと、自サイト内や外部サイトのコンテンツ(動画やJavaScriptライブラリなど)を呼び出すURLがhttp://~のままで残っている場合があります。

暗号化コンテンツの中に非暗号化コンテンツが混入していては、暗号化の存在意義であるセキュリティが確保されません。そこで、Googleは、暗号化コンテンツからの非暗号化コンテンツ読み込みを遮断する方針を以前から発表していました。その変更が、Chrome80・81で本格的に実装されます。

  • Chrome 80 (2020年2月予定) … 暗号化ページ内の音声・動画のURLがhttp://~の場合、強制的にhttps://~に置き換えて読み込む
  • Chrome 81 (2020年3月予定) … 暗号化ページ内の全コンテンツについて、URLがhttp://~の場合、強制的にhttps://~に置き換えて読み込む

https://~に強制変換されたURLに同じコンテンツがない場合は、その部分は読み込み失敗となります。仕様変更が行われる前に、必要な移行処理を行っておく必要があります。

対策

Webサイト管理者が行うべき対策は大きく2つです。

  • 外部コンテンツ/ライブラリの呼び出しURLがhttpになっている場合はhttpsに変更します。
  • 自サーバでhttp用領域にしかないコンテンツが残存している場合、https側にコピーし、httpsに完全移行します。

参考サイト

[C]TLS 1.0/1.1による暗号化通信無効化への対応

概要

Chrome 81 (2020年3月)以降、古い暗号化方式であるTLS 1.0/1.1がChromeのサポートから外されます。

サーバーで対応している暗号化方式がTLS 1.0/1.1までのみ(1.2以降に未対応)の場合は、TLS 1.2以降への移行が必要です。

対応を行わない場合、サイト接続時に警告画面が挿入され、事実上サイトへのアクセスが遮断されます

解説

Webの暗号化通信は、暗号解読技術が向上すると、いつかは解読されてしまいます。これを避けるため、より解読の難しいバージョンが開発・規格化された場合、解読が進む前に新方式に移行することが推奨されています。

現在主流のバージョンはTLS 1.2(2008年~)・TLS 1.3(2018年~)です。

比較的古いTLS 1.0(1999年~) / TLS 1.1(2006年~)は脆弱性が指摘されており、暗号解読が可能になっていることから、現在使用は非推奨となっています。が、これまで各主要ブラウザはTLS 1.0/1.1を有効な暗号化通信とみなしていました。

Chrome 81では、TLS 1.0/1.1のサポートを完全に廃止します。暗号化バージョンがTLS 1.0/1.1までの場合は、サイト接続時に警告画面が挿入され、事実上サイトが見えなくなる予定です。(有効なSSL証明書がないのにhttps://~を使っているサイトと同じ状態になります)

このため、TLS 1.2以降への移行により、暗号化通信を維持することが重要になります。

対策

Webサイト管理者が行うべき対策は大きく2つです。

  • 自サイトの暗号化通信(SSL/TLS)の状態を確認します。デジサートなどがWeb上でチェックツール新しいウィンドウで開きますを提供しており、ホスト名(ドメイン)を入れるだけで、無料で設定状態が確認できます。
    また、Chrome 79では、既にTLS 1.0/1.1はアドレスバーのセキュリティ表示が錠アイコンから[保護されていない通信]に格下げされているため、アドレスバーの表示も確認しておくと安全です。
  • 暗号化方式がTLS 1.0/1.1までのみ(1.2以降に未対応)の場合、Webサーバーの設定を変更してTLS 1.2以降(最新版は1.3)に対応させたうえで、サイト全体を暗号化通信対応(https://~)させる必要があります。Webサーバーの状況によっては構成の変更や更新が必要な場合があります。

参考サイト

マックスマウスでは、大規模サイトから中小サイトまで、様々な業種向けにWebサイト構築・リニューアル・運用・改善サービスを提供しております。ご興味のある方はぜひお問い合わせください。