Cookieにかわる Sec-HTTP-State ヘッダの提案

Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。

現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。

この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。

現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて共有されたり、パスを指定して共有されたりもします。また、Secure属性やHttpOnly属性の利用率は10%以下であり、SameSite属性では0.06%以下となっています。使用されているデータ量も多く、ブラウザによる統計の中央値ではドメインあたり409バイト、99パーセンタイルでは4,601バイトにもなります。

ここまでのCookieの改善など

Cookieをどうにかしたいという要望は根強く、2010年にもAdam Barth氏より「Simple HTTP State Management Mechanism」という提案仕様でcookieならぬ"cake"ヘッダが提案されていました。その後「Origin Cookies」と改題されましたが標準化されることはありませんでした。

既存のCookieの仕様である「RFC 6265 - HTTP State Management Mechanism」に"Cookie Prefixes"や"Same-Site"を追加した改定仕様も進行中ですが、その利用率は低いままです。
asnokaze.hatenablog.com

そういった中で、Cookieに変わる新しいステート管理の新しい仕組みを定義し、Cookieから徐々に移行できるようにと出てきたのが「Tightening HTTP State Management」です。

Sec-HTTP-Stateヘッダ

Cookieの持つ様々な問題を解決するために、「Simple HTTP State Management Mechanism」の仕様では、ブラウザがセキュアなオリジン(HTTPS, WSS)にアクセスする際に256bitのトークンをSec-HTTP-Stateヘッダに付加して送信します。

Sec-HTTP-State: token=*J6BRKagRIECKdpbDLxtlNzmjKo8MXTjyMomIwMFMonM*

サーバはこのトークンを用いてステート管理を行うことになります。

このSec-HTTP-Stateヘッダは以下の特徴を持ちます。

  • Clientがトークンを発行します
  • このトークンはJavaScriptやService Workersからはアクセスできない
  • この256bitのトークンはオリジン毎に生成され、そのオリジンのみに送信されます
  • 非セキュアなオリジン(HTTP, WS)では生成されない
  • same-siteへのリクエスト時のみ送信される(Third-Partyには送信されない)
  • トークンはサーバ、ユーザ、ブラウザによってリセットされるまで保持される

もちろん、サーバ側からトークンを発行可能にするかなどの議論はされるでしょう。

Sec-HTTP-State-Optionsヘッダ

サーバ側からトークンのオプションを指定する事もできるようになっています。HTTPレスポンスでSec-HTTP-State-Optionsヘッダで指定します。すでにいくつか考えられています。

Cross-Siteアクセス

Sec-HTTP-State-Options: ..., delivery=cross-site, ...

Sec-HTTP-State-Options: ..., delivery=same-origin, ...

TTL

Sec-HTTP-State-Options: ..., ttl=3600, ...

Sec-HTTP-State-Options: ..., ttl=0, ...