✨

ブラウザに拒否されないSet-Cookie ヘッダーのDomain属性

に公開
cookie
tech

目的

  • Set-Cookie ヘッダーのDomain属性には何が指定できるか理解する。
  • フロントエンドとバックエンドを別ドメイン（またはサブドメイン）で運用する場合に、ブラウザに拒否されないSet-Cookie ヘッダーの Domain 属性の値を理解する。

筆者は↑↑の実装をするときに、Domain属性について調べました。

用語

  • Response header: http(https)のレスポンスにつくヘッダー。
  • Cookie: ブラウザに保存されるデータで、サーバーへのリクエスト時に送信される。key-value形式の値
  • Set-Cookie ヘッダー: Response header の一部。ブラウザに、Cookieの登録,更新,削除を依頼するもの。
  • Domain属性: Set-Cookie ヘッダーにつける属性の1つ。「Domain=<domain-value>」のように指定し、クッキーが送信されるホストを定義する。ここにどのようなホストが設定できるかがこの記事の主題。
  • ホスト: 今回の文脈だと、ブラウザからからのリクエスト先のこと。
  • ドメイン: https://app.example.com/users/profile/editに対し、example.comの部分。
  • サブドメイン: https://app.example.com/users/profile/editに対しappの部分。
  • パス: https://app.example.com/users/profile/editに対しusers/profile/editの部分。
  • TLD: 後述
  • eTDL: 後述
  • eTLD+1: 後述

Set-Cookie ヘッダーの例

Set-Cookieの例

  • 上の画像はBetter Authで認証情報に関するCookieの設定する際のSet-Cookieヘッダーです。
  • __Secure-better-auth.session_token=...の値は本来晒してはいけない値です。(記事の公開前にリセットしています。)
  • Set-Cookie ヘッダーの部分を下に抜き出してみましょう。
__Secure-better-auth.session_token=igAHuroQOvhGFoGjtAWBH6vqPfeaEzZN.KtE9bluGLfl%2B9xo94XdWL5kO28dT2H7vH0W488JSdKg%3D; HttpOnly; SameSite=Lax; Secure;
Path=/; Domain=.fatricepaddy.workers.dev; Max-Age=604800
  • __Secure-better-auth.session_token: ブラウザに登録するCookieの名前。
  • HttpOnly: JavaScript からCookieを読み取れないようにするフラグ。
  • SameSite=Lax:
    • eTLD+1が同じであればCookieを送る。(例外あり)
    • ここで言う「同じ」の比較対象は以下です。URLに対して、eTLD+1という値が定まります。
  • Secure: https通信のときのみ、Cookieを送信する。
  • Path=/: どのパスでCookieを送信するか。/なので、全てのパスでCookieを送信する。
  • Domain=.fatricepaddy.workers.dev: fatricepaddy.workers.dev:
    • ドメインとそのサブドメインにのみCookieを送信する。
    • 設定されたDomainがルールを満たさない場合、このSet-Cookieリクエストは拒否され、Cookieはブラウザに保存されません。
    • このルールを満たすようにDomain属性を指定する必要があります。

TLD, eTLD, eTLD+1

  • 用語でしっかりと説明すると難しいですが、具体例を見るのがわかりやすいかと思います。
ドメイン TLD eTLD eTLD+1
example.com com com example.com
example.jp jp jp example.jp
example.co.jp jp co.jp example.co.jp
example.org org org example.org
example.workers.dev dev workers.dev example.workers.dev
example.github.io io github.io example.github.io
example.ac.uk uk ac.uk example.ac.uk
  • TLD: ドメイン名の最後のドットの後ろの部分。
  • Public Suffix List: いろんな組織が直接ドメインを登録できる末尾（サフィックス）の一覧。
  • eTLD: Public Suffix List（PSL）に載っているサフィックス(末尾)の値のこと。
  • eTLD+1: お名前.comなどで取得できるやつです。WebサイトのURLなどに直接利用されます。
  • TLDとeTLDが同じ場合もありますし、そうでないときもあります。ただの記号なので、そんなに深く考えなくていいと筆者は考えています。

ブラウザに拒否されないSet-Cookie ヘッダーのDomain属性

  • ここで言う「ホスト」は ブラウザで開いているページ (URL: https://frontend.example.com/...)に対し、「ホスト=frontend.example.com」
  • Domain属性は省略してもよい。その場合は「Domain属性の値=ホスト」としてブラウザに保存される
  • ホストがDomain属性の値のサブドメインについて:
    • 「ホスト = frontend.example.com」,「Domain=example.com」のとき、ホストはDomain属性のサブドメインであり、example.comはPublic Suffix Listに入っていないので、ブラウザに拒否されない。
    • 「ホスト = frontend.example.com」, 「Domain = api.example.com」のとき、ホストはDomain属性のサブドメインではないので、ブラウザに拒否される。

参考文献

https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Set-Cookie

https://developer.mozilla.org/ja/docs/Glossary/Response_header

https://developer.mozilla.org/ja/docs/Glossary/TLD

https://developer.mozilla.org/en-US/docs/Glossary/eTLD

https://wiki.mozilla.org/Public_Suffix_List

Discussion