要約

  • RFC 10025は、Cookieを作る側には整った狭い形式を、消費する側には既存実装と共存するための寛容な処理を求める。正しいSet-Cookieでも、無視、拒否、正規化、置換、早期削除が起こり得る。
  • 保存された事実は次の要求で送られる保証ではなく、送られた事実は操作の認可ではない。値そのものを記録せず、各判断を結ぶライフサイクル受領記録が必要である。

ある更新後、認証サービスは期待どおりの応答を返した。監視はステータスとSet-Cookie行を確認し、「セッション作成成功」とした。しかし後続要求は匿名だった。別の端末からは同名のCookieが二つ届いた。

この時点では、通信障害もブラウザー障害も証明されていない。接頭辞の条件が足りず受入れを拒まれたのかもしれない。端末の方針が第三者文脈を止めたのかもしれない。保存後に同じ名前・ドメイン・パスの行で置き換えられた、セッション終了時に消えた、容量制限で追い出された、あるいは後続URIの範囲外だった可能性もある。

RFC 10025は2026年7月に発行されたIETF Standards Track文書で、RFC 6265を廃止してCookieとSet-Cookieを定義した。応答は名前、値、属性を利用者エージェントへ渡す。後の要求は、選ばれた名前と値を返す。保存属性や選択理由を送り返す仕組みではない。

作る側と受ける側は同じ約束をしない

Cookie生成実装は、相互運用しやすい整形式のプロファイルに従うべきだとされる。Cookie消費実装は、現実のサーバーがそのプロファイルから外れるため、より寛容な処理規則を実装しなければならない。この非対称性はWebの互換性を支えるが、双方が同じ状態を共有したという確認にはならない。

したがってサーバー側の検査が証明できるのは、送出文字列が生成側の条件に合うことまでである。受け側のエンジン、方針の版、応答を受けた文脈、処理アルゴリズムの分岐は分からない。RFCの保存モデルは、受信Cookie全体を利用者エージェントが無視してよいという判断から始まる。

責任主体も別々だ。アプリは応答内容を決め、HTTP実装は複数のSet-Cookieを不正に結合せず運ぶ。利用者エージェントは解析と保存を担い、利用者や端末管理者は方針を変え得る。ナビゲーション、埋め込み文書、worker、非HTTP APIが次の取出し文脈を作り、最後にサービスがセッションと権限を判定する。

受入れは文字列の複写ではない

禁止された制御文字、名前と値の長さ超過、受け入れられないDomain、属性や接頭辞の条件違反は保存を止める。SameSite=NoneにはSecureが必要である。__Secure-と__Host-の名前は、それぞれの条件を満たした時だけ意味を持つ。利用者エージェントが接頭辞を大文字小文字を区別せず調べるのは、サーバー側の曖昧な比較から偽の保証が生まれるのを防ぐためだ。

受け入れた行には名前と値だけでなく、実効期限、ドメイン、パス、作成時刻、最終アクセス時刻、永続、ホスト限定、secure-only、http-only、same-siteの各状態が入る。Max-AgeはExpiresより優先される。Domainがなければホスト限定になる。置換の同一性は名前だけでなく、名前・ドメイン・パスの組で決まる。

送出文字列と保存結果の間には、解釈という決定がある。監査は秘密を除いた命令の指紋、受入れ可否、拒否分類、正規化後の範囲を分けなければならない。そうしなければ、構文誤り、プライバシー方針、範囲違反、正当な置換がすべて「Cookieがない」に潰れる。

期限は保管契約ではない

サーバーが指定するのは最大寿命であり、保存領域の予約ではない。利用者エージェントは期限を調整し、年齢上限を適用し、期限切れを削除し、ドメイン別または全体の上限を超えた行を追い出せる。利用者による削除や方針上の消去もあり、非永続行は利用者エージェントが定義するセッション終了時に消える。

「来年まで有効」は生成者の希望を表すにすぎない。必要なのは、実効期限、置換、明示削除、セッション終了、容量超過、方針変更のどれが保持を終わらせたかという記録である。

ただし、その記録を外部サイトへ全面送信する必要はない。管理下の端末では境界内に詳細を残せる。一般利用者については、粗い理由分類、集計、同意を得た診断に絞るべきだ。Cookie値や無関係な閲覧状態を観測の代償にしてはならない。

要求ごとに選択はやり直される

保存行が存在しても、取出し時には具体的URI、same-site状態、HTTPか非HTTPかという種別で再評価される。期限、ホストまたはドメイン、パス、安全な通信、HttpOnly、SameSiteの条件から外れれば送られない。方針によりCookieフィールド全体を省略することもできる。

WHATWG FetchはCookieをWeb要求のcredentialsに含める。HTMLのdocument.cookieは非HTTP APIで、HttpOnly行には触れられない。最上位文書、祖先文書、reload、共有worker、service workerでは「Cookie用のsite」を決める材料が違う。最終URLだけを残しても選択を再現できない。

SameSiteも許可証ではない。Strict、Lax、None、Defaultは文脈で働き、互換モードでは最近作られたDefault行に短い例外を設け得る。RFCはSameSiteをCSRFへの多層防御と位置づけ、万能の防御とはしていない。また属性を選ぶのはサーバーであり、利用者の意思表示ではない。

戻るのは値であり、履歴ではない

要求のCookieには通常、名前と値だけが並ぶ。Domain、Path、SameSite、作成時刻、今回選ばれた理由は戻らない。ドメインやパスが違えば同名行も共存でき、サーバーは並び順を業務上の優先順位として信頼すべきではない。

RFC 9113とRFC 9114が扱うHTTP/2・HTTP/3では、一つのCookie文字列が複数フィールド行に分けて運ばれる場合もある。運び方から保存元を逆算することはできない。

受信後にはさらに、サーバーの解析、セッション検索、失効・回転の確認、主体の認証、要求元の検証、資源認可がある。RFC 9110のHTTP意味論だけでアプリの権限は決まらない。

RFC 10025がCookieをambient authorityと呼ぶ理由もここにある。第三者が要求先を誘導し、Cookieの秘密を知らなくても、利用者エージェントが自動的に権限を添えることがある。Cookieが来たことは利用者の操作意思を証明しない。来なかったことも、利用者が明示的に拒否した証明ではない。

六つの受領記録を一本につなぐ

送出記録には応答URL、時刻、順序を保ったSet-Cookie行、リリースと設定の識別子、値を隠した指紋を置く。受入れ記録には消費エンジン、実効方針、解析結果、拒否分類を置く。保存記録には正規化範囲、フラグ、実効期限、置換関係と作成時刻の扱いを置く。

保持記録は観測可能な範囲で期限切れ、削除、セッション終了、置換、追出しを示す。取出し記録は要求URI、メソッド、起点、最上位文脈、SameSite計算、採用または保留した不透明IDを結ぶ。アプリ記録は解析、セッション、認証、CSRF対策、認可、結果を別々に示す。

これはDaniel Kadeによる運用ガバナンス案であり、RFC 10025が要求するテレメトリーではない。値、Bearer token、セッション秘密を記録しないことが前提である。

Heng Luのいう動くコードを第一の証拠とする姿勢なら、設定、送出バイト、保存遷移、要求、判定を別々に見る。Policy Mirrorは各判断の主体を映し、サーバーの希望をクライアントの事実に変えない。現実を製品とするとは、この狭い証明を守ることである。

情報源