先に要点
- Cookie の SameSite 属性は CSRF 対策の中核で、SameSite=Lax がデフォルト(Chrome 80 以降、2020 年〜)。「クロスサイトリクエストでは Cookie が送信されない」 のが現代の標準動作。
- クロスサイトで Cookie を送るには SameSite=None + Secure(HTTPS) 必須。「SameSite=None だけ」 は許容されず Cookie が落ちる。「埋め込みウィジェット / OAuth リダイレクト / 決済 SDK」 で必須の設定。
- Partitioned Cookie (CHIPS - Cookies Having Independent Partitioned State) は 埋め込まれた iframe ごとに別 Cookie ストレージを持つ仕組み。「Chrome 114+ で対応」、「第三者 Cookie 廃止後も埋め込みウィジェットを動かす」 ための代替手段。
- 第三者 Cookie 廃止は Apple Safari は 2020 年に完全廃止、Firefox は 2022 年に厳格制限、Chrome は 2025 年に方針転換して「ユーザー選択制」になった。「完全廃止」 ではないが、「第三者 Cookie に依存しない設計」 が現代の標準。
- 実務対応の優先順位: ① クロスサイト Cookie は必ず SameSite=None + Secure、② 埋め込みウィジェットは Partitioned Cookie に対応、③ 広告 / トラッキングは第三者 Cookie 非依存の方法(Privacy Sandbox / Server-side Tagging)に移行。CORS 設定も合わせて見直す。
「クロスサイトの fetch で Cookie が来ない」 「埋め込みの iframe でログイン情報が共有されない」 「OAuth リダイレクトが効かない」 ── これらの問題はすべて Cookie の SameSite 属性と 第三者 Cookie 廃止の流れに起因します。
2020 年に Chrome が 「SameSite=Lax をデフォルトにする」 大きな変更を行ってから、Web の Cookie の挙動はガラッと変わりました。さらに 2024 年から Partitioned Cookie (CHIPS) という新仕様が標準化され、「埋め込みウィジェットがどう Cookie を扱うか」 の選択肢が増えています。
この記事では、「Cookie の SameSite / Partitioned / 第三者 Cookie 廃止」 の現状と実務対応を整理します。CORS のハマりパターン と合わせて読むと、「Cookie が来ない問題」 の全体像が見えます。
SameSite 属性 — CSRF 対策の中核
SameSite は Cookie の属性で、「どんなコンテキストで Cookie を送るか」 を制御します。
| 値 | 動作 | 典型用途 |
|---|---|---|
| SameSite=Strict | 同一サイトからのリクエストでのみ送信 | 銀行 / 高セキュリティアプリ。外部リンクから来た時も Cookie 送られない |
| SameSite=Lax | 同一サイト + トップレベルナビゲーション(GET のみ) | Chrome 80+ のデフォルト。一般的な Web アプリ |
| SameSite=None | クロスサイトでも送信(Secure 必須) | 埋め込みウィジェット / OAuth / CDN / 第三者 API |
「明示しない場合は SameSite=Lax 扱い」 が Chrome 80 以降のデフォルト動作。過去の 「デフォルト = なし(クロスサイト可)」 とは挙動が違うので、古いコードがこの変更で動かなくなった事例が多発しました。
SameSite=None + Secure の必須化
「クロスサイトで Cookie を送りたい」 場合、SameSite=None + Secure (HTTPS) の両方が必須です。
SameSite=None だけは無効
「Set-Cookie: name=value; SameSite=None」 だけ書いても、Secure 属性がないと Cookie が破棄される。「SameSite=None; Secure」 の両方が必要。HTTPS 環境必須。
埋め込みウィジェット
「 Disqus コメント』 『 YouTube 埋め込み』 『 決済 SDK」 のような iframe 埋め込みウィジェットは 埋め込み元サイト(parent)から見て第三者 Cookie。SameSite=None + Secure が必須。
OAuth リダイレクト
「 Google ログイン → 認証完了 → 元サイトへリダイレクト」 のような OAuth フローでは、「認証サーバから戻る際の Cookie 送信」 で SameSite=None / Lax の挙動が効く。OIDC ライブラリが正しく Cookie 設定をしているか確認。詳しくは OAuth 2.0 と OIDC の違い。
Partitioned Cookie (CHIPS) とは
Partitioned Cookie (CHIPS - Cookies Having Independent Partitioned State) は 2024 年に標準化された新しい Cookie 仕様。「埋め込みコンテキストごとに別 Cookie ストレージを持つ」 仕組みです。
仕組み
「 example.com に埋め込まれた widget.com の iframe」 と 「another.com に埋め込まれた widget.com の iframe」 が それぞれ別の Cookie ストレージを持つ。「埋め込み元サイトごとに分離」 されるイメージ。
プライバシー利点
「 widget.com が複数サイトに埋め込まれていても、サイト跨ぎでユーザーをトラッキングできない」。第三者 Cookie によるクロスサイト追跡を防ぎつつ、機能的な Cookie は使えるのがメリット。
設定方法
「Set-Cookie: name=value; Secure; SameSite=None; Partitioned」 のように 「Partitioned」 属性を追加する。HTTPS 必須 + SameSite=None と組み合わせる。
第三者 Cookie 廃止の現状(2026 年)
「第三者 Cookie 廃止」 の流れは ブラウザごとに段階が違うのが現状です。
| ブラウザ | 第三者 Cookie の状態 | 備考 |
|---|---|---|
| Safari (Apple) | 完全廃止(2020〜) | ITP(Intelligent Tracking Prevention)で完全ブロック |
| Firefox (Mozilla) | 厳格制限(2022〜、Total Cookie Protection) | サイトごとに Cookie ジャー分離。第三者は実質使えない |
| Chrome (Google) | ユーザー選択制(2025〜) | 2024 年の完全廃止計画は撤回、「ユーザーが選ぶ」 形に方針転換 |
| Edge (Microsoft) | Chrome と同じ(Chromium ベース) | 「Strict / Balanced / Basic」 のトラッキング防止レベルあり |
「Chrome の完全廃止は中止された」 が、サイトの Web 設計は第三者 Cookie に依存しない方向に進めるべきです。Safari / Firefox では既に使えないので、「グローバル対応」 を考えると依然として廃止前提で設計するのが妥当。
Chrome 2025 年の方針転換
Google は 2020 年から 「Chrome で第三者 Cookie を 2024 年に廃止する」 と発表し、Privacy Sandbox という代替技術を開発してきました。しかし 2025 年に方針転換し、「ユーザーが第三者 Cookie の扱いを選ぶ形」 になりました。
何が変わったか
Chrome で第三者 Cookie が 「完全に廃止される」 ではなく、「ユーザーがプライバシー設定で選ぶ」 形 になった。「デフォルトは現状維持(第三者 Cookie 許可)」 だが、ユーザーがブロックを選べる UI を強化。
背景の事情
「 広告業界 / メディア業界からの強い反発』 『 Privacy Sandbox の代替技術が完全に成熟していない』 『 規制当局(英国 CMA など)の関与」 が方針転換の理由。「第三者 Cookie 廃止が完全に進む前にエコシステムの代替が間に合わない」 と判断。
サイト設計への影響
「 完全廃止が遠のいた」 ことで、「急いでの対応は不要」 になったが、「Safari / Firefox では既に使えない」 のは変わらない。長期的に第三者 Cookie 非依存の設計を進める方針は維持すべき。
実務対応の優先順位
「どんな順序で対応するか」 を整理します。
ハマりやすいポイント
実装で踏みやすい落とし穴を整理します。
SameSite=None だけで Secure 抜けで Cookie 落ち
「SameSite=None」 だけ書くと Cookie が破棄される。Secure(HTTPS 必須)とセット必須。ローカル開発(http://localhost)では Secure 付き Cookie が送れないので、「開発時は別のフラグ運用」 が必要。
localhost と本番で挙動が違う
「Secure 属性は HTTPS 必須」 だが、「localhost は例外的に HTTP でも Secure Cookie が送れる』(Chrome / Firefox)。本番と開発で Cookie 設定を分ける」必要があり、「本番のみで起きるバグ」 が発生しやすい。
サブドメイン共有 Cookie
「app.example.com から example.com の Cookie を読みたい」 場合、Domain=.example.com を Set-Cookie に明示。明示しないとサブドメイン共有不可。「サブドメイン間でログイン共有」 が突然動かない事故の原因。
Cookie の現代的なベストプラクティス
「現代の Web で Cookie をどう扱うべきか」 のベストプラクティスを整理します。
セッション Cookie は HttpOnly + Secure + SameSite=Lax
「 ログインセッション」 「CSRF トークン」 のような重要 Cookie は HttpOnly(JS からアクセス不可)+ Secure(HTTPS 必須)+ SameSite=Lax(CSRF 対策)を必ず付ける。XSS 経由の盗難リスクを構造的に防ぐ。詳細は JWT の正しい使い方。
第三者ウィジェット側は Partitioned 対応
埋め込みウィジェットを提供する側は Partitioned 属性を付けて、埋め込み元ごとに独立した状態を持つ。「プライバシー対応とサイトをまたいだ追跡防止」 の両立。
1st-party に寄せる設計
「 フロントと API を同じドメインにする」(BFF パターン)ことで、クロスサイト Cookie の問題を構造的に回避。「example.com/api/*」 のように同一サイト内で完結させる。
トラッキングは 1st-party Cookie + Server-side Tagging
「 広告 / アナリティクス」 は 1st-party Cookie ベース + Server-side Tagging(GTM SS / Stape など)に移行。「Google Analytics 4 + Server-side GTM」 で第三者 Cookie 非依存の設計が標準化。
Cookie 周りに関するよくある質問
Q. SameSite=Lax でフォーム送信が動かなくなりました
A. 「POST メソッド + クロスサイト」 で Cookie が送られないのが原因。SameSite=Lax は GET のトップレベルナビゲーション以外でクロスサイト Cookie を遮断します。「同一サイト内でフォーム送信」 なら問題なく、「クロスサイトの POST(OAuth コールバック / 第三者フォーム)」 で必要な Cookie は 「SameSite=None + Secure」 に変更。
Q. Chrome で 「SameSite=None」 を付けたのに Cookie が落ちます
A. Secure 属性が抜けている。「SameSite=None」 単独は Cookie 破棄、必ず 「SameSite=None; Secure」 のセット。本番は HTTPS 必須なのでこれが効くが、HTTP のローカル開発環境では Secure 付き Cookie が送れないので開発時の設定を分ける必要がある(localhost は Chrome / Firefox で例外的に許容)。
Q. Partitioned Cookie はすべての埋め込みで使うべき?
A. 埋め込みウィジェットを提供する側は対応推奨。「埋め込み元ごとに独立した Cookie ストレージ」 が必要なケース(ユーザー設定の保存、ログイン状態の維持)では Partitioned が有効。Safari がまだ非対応なので、「Partitioned で動くブラウザ」 と 「動かないブラウザ」 のフォールバックを設計する。
Q. 第三者 Cookie 廃止で広告計測が壊れた場合は?
A. Server-side Tagging への移行が現代の答え。「Google Tag Manager Server-side」 や 「Stape」 などのサービスで、1st-party Cookie ベースの計測を構築。「Meta Conversions API」 や 「Google Enhanced Conversions」 も組み合わせて、「第三者 Cookie に依存しない広告計測」 に移行。
Q. CSRF 対策に SameSite=Lax で十分?
A. 「ほぼ十分だが、CSRF トークン併用が安全」。SameSite=Lax は クロスサイト POST を遮断するので CSRF の大半を防ぐが、同一サイト内の脆弱性(リダイレクト経由攻撃など)では効かない。CSRF トークンを追加で実装するのが多層防御の現代標準。
Q. iframe で埋め込まれた自社サイトの Cookie が落ちます
A. SameSite=None + Secure + Partitioned の組み合わせが現代の標準対応。「example.com の iframe を partner.com に埋め込み」 すると 第三者 Cookie 扱いになる。SameSite=None + Secure で送信は許可、Partitioned で各埋め込みごとに分離されたストレージを持つ。
Q. Cookie より localStorage / sessionStorage を使うべき?
A. 用途で使い分け。「サーバとの自動共有が必要」(セッション、CSRF)なら Cookie、「クライアント内だけで完結」(UI 設定、キャッシュ)なら localStorage。localStorage は XSS で全部漏れるリスクがあるので、「認証トークンを localStorage に置かない」 が鉄則。詳しくは JWT の正しい使い方。
まとめ
Cookie の SameSite / Partitioned / 第三者 Cookie 廃止は、「現代の Web セキュリティ + プライバシー対応の核心」で、すべての Web 開発者が押さえる必要があります。
「SameSite=Lax がデフォルト + クロスサイトには None + Secure + Partitioned」 という現代の Cookie 設計を理解し、1st-party に寄せる設計(BFF パターン、同一ドメイン API)で構造的に問題を回避するのが現代の標準。「第三者 Cookie 廃止は Chrome で方針転換されたが、Safari / Firefox では既に使えない」 ので、長期的には非依存設計を進めるのが妥当。CORS のハマりパターン と合わせて、「Cookie が来ない / 認証が動かない」 系のトラブルを構造的に減らせます。
参考リンク
- MDN: Set-Cookie SameSite
- web.dev: SameSite Cookies Explained
- W3C: Cookies Having Independent Partitioned State (CHIPS)
- Google: Chrome の第三者 Cookie 方針(2025)
- web.dev: Partitioned Cookies