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, ...
Sec-HTTP-State-Options: ..., ttl=3600, ... Sec-HTTP-State-Options: ..., ttl=0, ...
