Chromeが「Cookie の SameSite=Lax をデフォルト化」を進めたことは記憶に新しい。
asnokaze.hatenablog.com
Cookieの改善は引き続き議論されており、Cookieの扱いでスキーム（http://やhttps://）を考慮に入れることが検討されている。
Incrementally Better Cookies
Cookieのセキュリティ改善を精力的に行っているGoogleのMike West氏は、Secure属性の利用が30%、"__Secure-"プレフィックスの利用が0.18%ほどにとどまっていると述べており(リンク)、セキュリティ改善のためにCookieの扱いを段階的に変更していくことを考えている。
同氏がIETFに提出している「Incrementally Better Cookies」では、Cookieを次のように段階的に改善することを提案している。
- 「SameSite = Lax」をデフォルトにする
- 「SameSite = None」にするにはHTTPSから配信される必要がある
- same-siteはスキームを考慮にいれるようにする (Schemeful Same-Site)
- Cookieはスキームを尊重する必要がある (Scheming Cookies)
- 非セキュアなスキームのCookieは、セッションの最後に削除する
- セッションの定義を厳しくする
すでに、最初の2つは実施されている。これに続く、Schemeful Same-Siteや、Scheming Cookiesなどについて簡単に書いていく。
ただし、同氏がBlink-devで「Reducing web compatibility risk.」述べているように、昨今の状況を鑑みてWebの互換性を壊しうる変更はすぐにブラウザには入らないだろう。
Schemeful Same-Site
Same-Site の判定は、eTLD+1である。
例えば下記はsame-siteである。
また、https:// と http:// は考慮に入らないが、Schemeful Same-Siteではスキームを考慮にいれるという変更である。
Same-site Cookieの場合は、https://example.comでセットされたcookieは.http://www.example.com へのリクエストでは付加されません。逆もそうなります。
