61
57

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

「Chrome 80」でのクッキー(Cookie)の心構え 〜 SameSite属性・Secure属性 〜

Last updated at Posted at 2020-01-11

ニュース

:point_up: 2020年1月23日
「トラッキング企業の対応策」を更新

:point_up: 2020年1月15日
Google Chrome が 3rd Party Cookie の2年における段階的廃止を発表

概要

2020年2月にリリースされる予定の Chrome バージョン80でサードパーティクッキー(3rd Party Cookie)の扱いが大きく変わり、端的にいうと制限が厳しくなります。

Cookie を管理しているデベロッパーの皆さんはすぐに準備状況を評価することが重要です。

と本家、Google 様も注意喚起をしております。

これまでブラウザを利用した計測ツールでは3rd Party Cookie利用した手法が一般的でした。
アフィリエイト(トラッキング)やレコメンド広告表示などがその類です。
しかし、Chrome 80 の影響で、この 3rd Party Cookie の扱いが大きく変わります。
何も対応しないと 今までの Cookie の埋め込み方法では計測等が失敗してしまう可能性があります。

Chrome 80 でどうなる?

特定の属性を付与しない限り 3rd Party Cookie にアクセスできなくなります。

Chrome80 以降、SameSite 値が宣言されていない Cookie は SameSite=Lax として扱われます。
外部アクセスは、SameSite=None; Secure 設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。

これまでの 3rd Party Cookie の動作を保つためにはSameSite=Noneを指定する。しかし SameSite=NoneSecure属性が必須になる。片方だけではダメということですね。
それではさっそく、SameSite 属性と Secure 属性 とで分けて深掘りしていきましょう。

1. SameSite 属性

以下のように3つの種類があります。

名前 説明 備考
Strict 3rd Party Context からは Cookie がセットされない Strict=厳しい
Lax 3rd Party Context からは POST・iframe・XHR 等のリクエストに Cookie がセットされない Lax=厳しくない・緩い
None Cookie 送信する None=なし

※ 3rd Party Context はクロスドメインと捉えて頂いて問題ないかと思います

Strict が一番制限がきつく、Lax、None と緩くなっているのがわかります。
そして Chrome 80 では SameSite 属性を指定しないと真ん中の Lax として扱われるようになるというわけです。

様々なプログラミング言語においての SameSite 属性の埋め込み方のサンプルがあります。
GitHub - GoogleChromeLabs/samesite-examples:

2. Secure 属性

こちらはシンプルです。

HTTPS 通信時にのみクッキーを送信できるようになる です。

3. SameSite 属性と Secure 属性の組み合わせ

さて、先ほどの話に戻ります。

外部アクセスは、SameSite=None; Secure 設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。

SameSite=None; Secure の意味は、

  • SameSite=None ==> Cookie のアクセス制限ルールを撤廃
  • Secure ==> HTTPS環境必須

という事になります。
SameSite=None を指定したとしても、Secureな(HTTPS)環境がないと意味がなくなってしまうわけですね。
逆に言えば Secureな(HTTPS)環境があったとしても、SameSite=None を指定しないと、Lax がデフォルトで適用されてしまうので、 3rd Party Cookie のアクセス制限ルールが適用されてしまいます。

実験1

SameSite=None; Secure で Cookie を埋め込んでみよう。

php
if (PHP_VERSION_ID < 70300) {
    setcookie($name, $value, $expires, '/; SameSite=None;', null, true, false);
} else {
    setcookie($name, $value, [
        'expires' => $expires,
        'path' => '/',
        'samesite' => 'None',
        'secure' => true,
    ]);
}

PHP のバージョンによって、セットする書き方がかわるため、バージョン分岐させております。

第4引数の /; SameSite=None; と第6引数の true(Secure) が重要な箇所です。さてChromeブラウザはどのように表示されるのか、デベロッパーコンソールを見てみましょう。

スクリーンショット 2020-01-11 23.03.58.png

無事、Secure にはチェックマークが入り、 SameSite には None が指定されております。

実験2

SameSite=None; Secure × 非SSL(http)環境の組み合わせで Cookie を埋め込んでみたいと思います。
これまでの説明から上記の Secure 属性が必須となったことにより、非SSL(http)環境からCookie埋め込みは失敗するはずです。

Cookie_bokasi.png

画像が小さくてわかりづらいかもしれませんが、一番最後の部分が肝です。
secure の後ろに黄色の注意喚起マークが表示されております。無事埋め込みが失敗しました。

なおテストには最新バージョンが利用できる Google Chrome Canary を利用しました。

まとめ

これまでの 3rd Party Context (クロスドメイン)における、Cookie 計測を行っていたシステムを継続して利用する場合は、SameSite=None; Secure の2つの指定をCookie埋め込み事に行う必要がある。
しかし、Secure 属性が必須になったことでHTTPS環境が必須になるため、現在環境がHTTPS環境になっていない場合は準備をする必要がある。

また、Apple のITP同様、Chrome も今後さらにバージョンアップしていくとともに、上記回避策も利用できなくなる可能性も多いにあります。SameSite=Laxがデフォルトになるということは、SameSite=Laxでも問題がないサービスに変化させていく必用も考慮してシステムをメンテナンスしていきましょう。

「Chrome 80」における広告企業の対応

Affiliate Platform「アフィリコード | Chrome 80での3rd Party Cookieのブロックとアフィリエイト運営に関して

トラッキング企業の対応策

最新情報

Google Chrome が 3rd Party Cookie の2年における段階的廃止を発表 したようです。 (2020.01.14 更新)

備考

Firefox や Microsoft Edge もこのモデルを適用するというアナウンスもあるようです。

参考

Google Developers Japan: 新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう

61
57
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
61
57

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?