CookieのHttpOnly・Secure・SameSiteは、何を変える？

ゲスト用Cookieの実装を読むと、二つのCookieに同じ属性と違う属性が付いていました。片方だけHttpOnlyなのはなぜでしょうか。実GuestCookieManagerへダミーの値を渡すと、資格用はHttpOnly付き、時刻を持つマーカーは付かないという違いが見えました。

Cookieは日記そのものではなく、通信で渡す小さな値

ゲストの記録はサーバー側に保存し、Cookieにはその利用者を識別するための値を持たせる構成です。日記本文をCookieへ丸ごと入れているわけではありません。 今回の検証は、実クラスへARTICLE_DUMMY_NOT_A_CREDENTIALという架空の文字列と固定のClockを渡し、Set-Cookieのヘッダー文字列を作るところまでです。ブラウザーにある実Cookieや実トークンは読み取っていません。

HttpOnlyは、JavaScriptから読む経路を制限する

HttpOnly付きのCookieは、document.cookieなどからJavaScriptで読み取れません。ただし、条件に合うHTTP要求へブラウザーがCookieを付けることまで止める属性ではありません。JavaScriptが始めたfetchでも送信対象になり得ます。 実クラスは資格用にだけHttpOnlyを付け、マーカーには付けません。マーカーに入るのは時刻の値で、資格用トークンそのものではありません。この違いは属性と生成値から確認したもので、マーカーだけで本人確認が済むという説明ではありません。

Secureは送信の通信路、SameSiteはサイト間の条件

Secureは、通常HTTPSでの要求へ送るための属性です。localhostにはブラウザーの例外があるため、「httpならどの環境でも絶対に使えない」とは言い切りません。また、値を暗号化して保存する属性でもありません。 SameSite=Laxは、同じサイトからの要求に加え、サイトをまたいでもトップレベルの安全な方法による移動などで送信を認めます。別サイトからのリンクでページを開く場合と、別サイトのJavaScriptからfetchする場合を、同じ条件として扱わないことがポイントです。

サイトをまたぐ通常のPOSTは、明示的なLaxの例外に含まれません。SameSiteを省略したときのブラウザー既定動作とは区別します。ここでは全条件の実機試験はせず、現行の公式説明と実装のLax指定を照合しました。

開発用と本番用で、Secureの設定値が違う

ローカルComposeはSecure設定の既定値をfalseにし、本番向け構成はtrueを渡しています。実クラスにもfalseとtrueの両方を渡すと、生成されるヘッダーのSecure属性が切り替わりました。 同じ関数でも、外から渡す設定で出力は変わります。実装内の初期値だけを見るのではなく、環境側が何を渡すかまで読む必要があります。これは設定コードと生成結果の確認で、本番ブラウザーの保存状況を検査したものではありません。

削除でも、どのCookieを対象にするかをそろえる

clearを呼ぶと、値を空にし、Max-Ageを0にしたヘッダーが二つ作られました。Pathは同じ/で、資格用のHttpOnly、設定に応じたSecure、SameSite=Laxも維持されます。このクラスはDomainを指定していません。 Cookieを消す際は、同じ名前に加え、設定時のPathやDomainの範囲を合わせる必要があります。今回確かめたのはヘッダーの生成までです。三属性を一つの「安全スイッチ」として覚えず、読む経路、送る通信路、サイト間の条件へ分けると、設定の意味を説明しやすくなります。

GuestCookieManager、ローカル・本番向け設定と照合しました。

確認日：2026年9月22日。実装・検証結果・公式資料は確認時点のものです。