cookie


概要

  1. 初回リクエスト(cookieなし)
  1. レスポンスヘッダにSet-Cookie
    • Webサーバが任意に付与
  2. リクエストヘッダにCookie
    • ブラウザが保持
    • 同じドメイン: 以降自動付与

機能

クロスサイト・リクエスト時のポイント


Set-Cookieレスポンスヘッダ

使える文字

各ヘッダごとに既定属性を付けられる


Cookieリクエストヘッダ

JavaScriptで付加・参照

document.cookie = 'test1 = true'
document.cookie = 'test2=abc' // 追加
document.cookie = 'test1=123' // 上書き
console.log(document.cookie) // test2=abc; test1=123

既定属性


Public Suffix Listとは

登録ドメインよりひとつ上となるドメインのリスト

  1. comjporg
  2. co.jpgithub.io
  3. chuo.tokyo.jp

Domain=SameSite=の動作に必須


登録ドメインとは

cookieの管理者の単位

ここではこの文脈で「登録ドメインとサブドメイン、サブドメインどうし」を「同じサイト」と呼ぶ。


Supercookie防止

Domain=: 「Public Suffix List」の指定は無効

無効になるもの(cookie未保存)

未指定と同様になるもの

有効なもの


SameSite=

前提: クロスサイト・リクエスト時

  1. 以前に設定済みのcookieが残っていて
  2. そのドメインへ、クロスサイト・リクエスト (ここではクロスオリジンではない)

宛先ドメイン所属のcookieを付けるかどうか

SameSite=Strict

SameSite=Lax

SameSite=None


SameSite=における「同じサイト」

登録ドメインとサブドメイン間、サブドメインどうし

例: example.comapi.example.com

  1. api.example.com所属のcookieが残存
    • Domain=指定なし
    • SameSite=Strict
  2. example.comからfetch()でJSONボディをapi.example.comPOST
    • cookie付き (「同じサイト」だから)
    • レスポンス利用はCORS対応が必要 (クロスオリジンだから)

レスポンスのcookieがブラウザに保存されるかどうか

サーバ側による制御

「同じサイト」のとき

クロスサイト・リクエスト時


fetch()credentialsオプション

クライアント側による制御

omit

same-origin

include

クロスオリジンなら

const init = {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // クロスオリジンでもcookie送信
}
fetch('http://別オリジン.example.com/パス', init).then(
  res => res.text()
).then(console.log).catch(console.error)

ACAC対応

レスポンスヘッダ: Access-Control-Allow-Credentials: true

credentialsオプションincludeのとき、必須

プリフライト発生しないケース

プリフライト発生のケース