先に要点
- 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 年から <strong>Partitioned Cookie (CHIPS)</strong> という新仕様が標準化され、埋め込みウィジェットがどう Cookie を扱うか』 の選択肢が増えています。
この記事では、Cookie の SameSite / Partitioned / 第三者 Cookie 廃止』 の現状と実務対応を整理します。<a href="/articles/cors-common-pitfalls-and-debugging-checklist">CORS のハマりパターン</a> と合わせて読むと、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 以降のデフォルト動作。<strong>過去の デフォルト = なし(クロスサイト可)』 とは挙動が違うので、古いコードがこの変更で動かなくなった事例が多発しました。
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 の完全廃止は中止された』 が、<strong>サイトの Web 設計は第三者 Cookie に依存しない方向に進めるべき</strong>です。Safari / Firefox では既に使えないので、グローバル対応』 を考えると依然として廃止前提で設計するのが妥当。
Chrome 2025 年の方針転換
Google は 2020 年から Chrome で第三者 Cookie を 2024 年に廃止する』 と発表し、<strong>Privacy Sandbox</strong> という代替技術を開発してきました。しかし <strong>2025 年に方針転換</strong>し、ユーザーが第三者 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 が送られない</strong>のが原因。SameSite=Lax は <strong>GET のトップレベルナビゲーション以外でクロスサイト Cookie を遮断</strong>します。同一サイト内でフォーム送信』 なら問題なく、クロスサイトの 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 が有効。<strong>Safari がまだ非対応</strong>なので、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 設計を理解し、<strong>1st-party に寄せる設計</strong>(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