Cookieが保存されない・ログイン状態が保持されない ─ SameSite・Secure属性とクロスサイト送信の切り分け

ログインは通る。なのに次のページでまた認証画面に戻される。カートへ入れた商品が遷移した瞬間に消える。「ログイン状態を保持する」を押しても、タブを開き直すと切れている。こうした症状の大半は、サーバ側のセッションが壊れているのではなく、ブラウザがCookieを保存していない、あるいは送信していないことが原因です。

2020年のChrome 80以降、SameSite属性を明示していないCookieは自動でSameSite=Laxとして扱われるようになりました。この一行の挙動変更が、数年前まで普通に動いていた仕組みを静かに壊しています。Laxのままだと、別ドメインからのPOST遷移、iframe内のページ、外部決済サービスからのリダイレクト直後でCookieが送られません。埋め込み型のチャットや、Stripe・GMOペイメントの決済画面から戻ってきた瞬間にセッションが切れるなら、まずここを疑います。

最初に開くのは、サーバが何を送っているかです。開発者ツールのNetworkタブで該当リクエストを選び、レスポンスヘッダのSet-Cookieを確認します。属性にSameSite=None; Secureが付いているか、Domainの指定が実際のホスト名と一致しているか、Expires/Max-Ageが過去になっていないか。ここでブラウザがCookieを弾いていると、Set-Cookieの行に警告アイコンが出ます。Applicationタブのストレージを見れば、保存されたのか拒否されたのかが一目で分かります。

クロスサイトでCookieを使うなら、SameSite=Noneは必須です。そしてNoneを指定したら必ずSecureを付け、配信はHTTPSに統一する。SecureなしのNoneはブラウザが無条件で破棄します。ここを片方だけ直して動かないと悩む現場を何度も見てきました。両方セットで初めて意味を持つ、と覚えておくのが正解です。

見落としやすいのがドメインの不一致です。www.example.comでログインしてexample.comに遷移している、サブドメインをまたいでいる、といったケースでは、Cookieのスコープが合わずに送信されません。サブドメイン横断で共有したいならDomain=.example.comを明示します。逆に、必要以上に広いDomain指定はセッション固定攻撃の入口になるため、共有が不要なら絞るべきです。

LaravelやWordPressで起きるのはたいてい設定の問題です。Laravelならconfig/session.phpのsame_site、secure、domainの三点。リバースプロキシやロードバランサ配下でHTTPSを終端していると、アプリがhttpだと誤認してSecure Cookieを出さないことがあります。TrustProxiesミドルウェアでX-Forwarded-Protoを信頼させると直ります。WordPressはCOOKIE_DOMAINとサイトURLの不整合、それからキャッシュプラグインがSet-Cookieごとページをキャッシュしてしまう事故が定番です。

2024年以降はもう一つ前提が変わりました。Chromeはサードパーティ Cookieの段階的な制限を進めており、別ドメインに埋め込まれた状態でのCookieは将来的に届かなくなる方向にあります。広告や解析だけの話ではありません。SSO、外部埋め込みウィジェット、決済の戻り処理など、業務システムの根幹がこれに引っかかります。対症療法でSameSite=Noneを付けて延命するのではなく、CHIPS（Partitioned属性付きCookie）への対応や、そもそもクロスサイトに依存しない設計へ寄せる判断が要る局面です。

切り分けの順序はシンプルに。送信側でSet-Cookieが出ているか、属性（SameSite/Secure/Domain/Path）が正しいか、HTTPSで配信されているか、ブラウザが拒否警告を出していないか、最後にサードパーティ文脈かどうか。この順で見れば、サーバの再起動やセッションドライバの入れ替えといった的外れな対処に時間を溶かさずに済みます。

それでもCookieが安定しない、あるいはサードパーティCookie廃止で認証や決済の戻りが壊れ始めている場合は、設計レベルの見直しが必要なサインです。ブラウザ側の仕様変更は今後も続きます。場当たりの属性追加で凌ぐほど、次の変更で再び止まる確率が上がります。