Cookie はなぜ壊れやすいのか ― SameSite / Secure / HttpOnly / Partitioned を正しく読む

HTTP は基本的にステートレスです。1回目のリクエストと2回目のリクエストを、プロトコルそのものは自動では結びつけません。Cookie はこの世界に「同じブラウザから来た続きのリクエストらしい」という状態を持ち込む仕組みです。

HTTP/1.1 200 OK
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

GET /account HTTP/1.1
Cookie: session=abc123

便利な一方で、Cookie は自動送信されます。ブラウザは条件に合うCookieを、ユーザーが明示的に選ばなくてもリクエストに付けます。この「自動で付く」性質が、ログイン維持を便利にする同じ理由で、CSRFやセッション盗難のリスクにもつながります。

Secure は、Cookieを安全な通信路でだけ送るための属性です。MDNの説明では、Secure が付いたCookieは通常 https: のリクエストでのみ送信されます。ログインセッションのCookieには基本的に必須と考えてよい属性です。

Set-Cookie: session=abc123; Secure

ただし、Secure はCookieの中身をアプリ内で安全にする魔法ではありません。ディスク上の保存、ブラウザ拡張、XSSで発生するリクエスト、サーバー側のセッション管理ミスまでは解決しません。また、JavaScriptからの読み取りを止める属性でもありません。そこは HttpOnly の役割です。

HttpOnly は、CookieをJavaScriptの document.cookie などから読めないようにする属性です。XSSが起きたときに、攻撃者のスクリプトがセッションIDを直接盗み出すリスクを下げます。

Set-Cookie: session=abc123; Secure; HttpOnly

ここで誤解しやすいのは、HttpOnly が付いていても、そのCookieはHTTPリクエストには送られるという点です。MDNも、XMLHttpRequest や fetch() によるリクエストでもCookieは送信されると説明しています。つまり、HttpOnly は「読み取り」を防ぐ属性であり、「そのCookieを使ったリクエスト」を止める属性ではありません。

したがって、XSS対策としては HttpOnly だけでは足りません。テンプレートエスケープ、CSP、入力検証、危険なHTML挿入の回避が必要です。Cookie属性は防御の一層であって、XSSそのものを消すわけではありません。

SameSite は、クロスサイトのリクエストにCookieを送るかどうかを制御します。CSRFは、攻撃者のサイトが被害者のブラウザに、ログイン済みサイトへのリクエストを送らせる攻撃です。OWASPも、ブラウザがセッションCookieを自動的に含めることがCSRFの前提になると説明しています。

注意点は、SameSite は認可ではないことです。攻撃リクエストの一部をブラウザ側で抑制できますが、サーバー側のCSRFトークン、Origin / Referer確認、Fetch Metadataヘッダー、再認証などを完全に置き換えるものではありません。

SameSite の「site」は、JavaScriptの同一オリジンポリシーでいう origin と同じではありません。origin は scheme、host、port の組み合わせです。一方、SameSiteで見る site は、現在の仕様やブラウザ説明では scheme と登録可能ドメインを中心に扱われます。

この違いを混同すると、「CORSで別originだからSameSiteでも別扱いだろう」といった誤解が起きます。Cookieの送信条件、CORSでレスポンスを読める条件、JavaScriptがDOMへアクセスできる条件は、それぞれ別のルールです。

Cookie名のプレフィックスも重要です。MDNは、__Secure- と __Host- などのCookieプレフィックスを説明しています。これらは、対応ブラウザでCookieの属性条件を強制し、設定ミスを見つけやすくします。

ログインセッションCookieでは、可能なら __Host- を検討する価値があります。Domain を指定しないhost-only cookieにし、Path=/ でホスト全体に限定すると、スコープが読みやすくなります。

Partitioned は、CHIPS(Cookies Having Independent Partitioned State)で導入された属性です。Chrome Privacy Sandboxの説明では、Partitioned Cookieはトップレベルsiteごとに別のCookie jarへ保存されます。

Set-Cookie: __Host-chat=value; Secure; Path=/; SameSite=None; Partitioned

たとえば support.chat.example が retail.example に埋め込まれたときに作ったCookieは、retail.example というトップレベルsiteの区画に紐づきます。同じ support.chat.example が別の news.example に埋め込まれても、同じCookieは共有されません。

これは、埋め込みチャット、地図、決済、CDNなど、第三者コンテキストでも状態が必要だが、サイト横断の追跡には使わせたくない場面のための仕組みです。CHIPSは「第三者Cookieを今まで通り使い続ける」技術ではなく、トップレベルsiteごとに状態を分けるための移行先です。

Cookieの属性が難しいため、「トークンをCookieではなくlocalStorageに置けばよい」と言われることがあります。しかし、これは単純化しすぎです。localStorageの値はJavaScriptから読めるため、XSSが起きるとアクセストークンを直接盗まれる可能性があります。

一方、HttpOnly CookieはJavaScriptから直接読めません。ただし、リクエストには自動送信されるため、CSRFやXSSによる操作リクエストには別の防御が必要です。つまり、CookieとlocalStorageは「どちらが常に安全」ではなく、攻撃面が違います。

セッション管理では、短命トークン、ローテーション、CSRF対策、再認証、権限チェック、ログアウト時の無効化、サーバー側セッション失効などを組み合わせる必要があります。保存場所だけで安全性を決めるのは危険です。

通常のログインセッションなら、まずは次のような形が出発点になります。サイトの要件によって SameSite=Strict に寄せるか、外部IdPや決済との連携で None が必要かを判断します。

Set-Cookie: __Host-session=...; Path=/; Secure; HttpOnly; SameSite=Lax

第三者コンテキストに埋め込まれるウィジェットで、トップレベルsiteごとに状態を分けたい場合は、CHIPSの Partitioned を検討します。

Set-Cookie: __Host-widget=...; Path=/; Secure; SameSite=None; Partitioned

ただし、これはあくまで形の例です。実際にはブラウザ対応、第三者Cookieブロック、CORS、iframeの権限、Storage Access API、ログイン方式、認可モデルまで含めて確認します。

Cookie属性は、名前だけ覚えるより「何から守るのか」で読むと整理できます。Secure は通信路、HttpOnly はJavaScriptからの読み取り、SameSite はクロスサイト送信、Partitioned は第三者コンテキストでの状態分離、__Host- はスコープ設定ミスの削減です。

逆に言えば、どの属性も万能ではありません。HttpOnly はCSRFを止めません。SameSite は認可を代替しません。Secure はXSSを防ぎません。Partitioned はすべての第三者Cookie問題を解決するわけではありません。

Cookieは壊れやすい技術ではありますが、壊れ方にはパターンがあります。属性を役割で読み、サーバー側の認可・CSRF対策・XSS対策と組み合わせれば、セッション管理の見通しはかなりよくなります。