先に要点
- Cookie の SameSite 属性は CSRF 対策の中核です。Chrome と Edge は、SameSite を書かない Cookie を Lax として扱います(Chrome 80、2020 年〜)。一方、2026年10月時点で Firefox と Safari はこの既定値を採用していないので、ブラウザ任せにせず属性を明示するのが安全です。
- クロスサイトで Cookie を送るには SameSite=None + Secure(HTTPS)を指定します。Chrome と Firefox は Secure の無い SameSite=None を拒否します。「埋め込みウィジェット / 決済 SDK / 別サイトからの POST」で必要になる設定です。
- Partitioned Cookie (CHIPS) は、埋め込み先のトップレベルサイトごとに Cookie を分けて保存する仕組みです。Chrome / Edge 114、Firefox 141、Safari 26.2 が対応し、2025 年 12 月に主要ブラウザがそろいました。
- 第三者 Cookieは、Safari が 2020 年から既定でブロック、Firefox が 2022 年からサイトごとに分離しています。Chrome は 2025 年に廃止計画をやめ、ユーザーが設定で選ぶ現行方式を続けると発表し、Privacy Sandbox の多くの API も終了を決めました。CHIPS と FedCM は継続です。
- 実務対応の優先順位: ① クロスサイト Cookie は SameSite=None + Secure、② 埋め込みウィジェットは Partitioned に対応、③ 計測や認証は第三者 Cookie に頼らない設計に寄せる。CORS 設定も合わせて見直します。
「クロスサイトの fetch で Cookie が来ない」「埋め込みの iframe でログイン状態が保てない」「別サイトから戻ってきた POST でセッションが切れる」── こうした問題の多くは、Cookie の SameSite 属性と第三者 Cookie の制限に起因します。
2020 年に Chrome が「SameSite を書かない Cookie を Lax として扱う」変更を行ってから、Cookie の挙動は大きく変わりました。その後、Partitioned Cookie (CHIPS) が Chrome 114(2023 年)で導入され、2025 年には Firefox と Safari も対応して、埋め込みウィジェットの Cookie の扱い方に選択肢が増えています。
この記事では、2026年10月時点の MDN の互換性データと、Google・WebKit・Mozilla の公式発表をもとに、SameSite / Partitioned / 第三者 Cookie の現状と実務対応を整理します。CORS のハマりパターン と合わせて読むと、「Cookie が来ない問題」の全体像が見えます。
SameSite 属性 — CSRF 対策の中核
SameSite は Cookie の属性で、「どんなコンテキストで Cookie を送るか」を制御します。
| 値 | 動作 | 典型用途 |
|---|---|---|
| SameSite=Strict | 同一サイトからのリクエストでのみ送信 | 高いセキュリティが必要な操作。外部リンクから来たときも Cookie は送られない |
| SameSite=Lax | 同一サイト + 別サイトからのトップレベルナビゲーション(GET などの安全なメソッド) | Chrome / Edge では属性なしの既定値。一般的な Web アプリのセッション |
| SameSite=None | クロスサイトでも送信(Secure 必須) | 埋め込みウィジェット / 決済 SDK / 別サイトからの POST を受ける場合 |
「明示しない場合は Lax 扱い」は Chrome 80 以降(と Chromium 系の Edge)の動作です。MDN の互換性データでは、2026年10月時点で Firefox は設定フラグでのみ、Safari は未採用となっています。同じ Cookie でもブラウザによって送られ方が違うので、SameSite は必ず明示しておくのが確実です。
MDN によると、Lax が既定値として適用される場合は、設定から 2 分以内の Cookie に限りトップレベルの POST でも送る、ゆるい版の Lax が使われます。明示的に SameSite=Lax と書いた Cookie にはこの例外がありません。テストでは動いたのに時間を置くと失敗する、という現象の原因になることがあります。
SameSite=None + Secure の必須化
「クロスサイトで Cookie を送りたい」場合は、SameSite=None と Secure (HTTPS) の両方を指定します。
SameSite=None だけは拒否される
「Set-Cookie: name=value; SameSite=None」だけ書くと、Chrome(80 以降)と Firefox(131 以降)は Cookie を受け付けません。Safari はこの制限を設けていませんが、ブラウザ共通で動かすために「SameSite=None; Secure」の両方を付けます。
埋め込みウィジェット
コメント欄・動画プレイヤー・決済 SDK のような iframe 埋め込みは、埋め込み元サイトから見ると第三者です。Cookie を使うなら SameSite=None + Secure が前提で、さらに第三者 Cookie の制限を受けます(後述)。
Partitioned Cookie (CHIPS) とは
Partitioned Cookie (CHIPS - Cookies Having Independent Partitioned State) は、「埋め込み先のトップレベルサイトごとに、別の Cookie 保存領域を持つ」仕組みです。Chrome が 114(2023 年)で既定有効にし、2025 年には Firefox と Safari も対応しました。
プライバシー上の利点
widget.example が複数サイトに埋め込まれていても、サイトをまたいで同じ Cookie を読めないので、クロスサイトの追跡には使えません。その一方で、埋め込み先ごとの設定保存やログイン状態の維持といった機能的な Cookie は使えます。
設定方法
「Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned」のように Partitioned 属性を追加します。Secure は必須です。MDN は、サブドメインで共有する必要がなければ __Host- 接頭辞を付けることを勧めています。
対応状況(2026年10月時点)
MDN の互換性データでは Chrome 114 / Edge 114 / Firefox 141 / Safari 26.2 が対応し、Baseline 2025(2025 年 12 月から主要ブラウザの最新版で利用可能)です。古い Safari などの未対応ブラウザでは、属性が無視された通常の Cookie として扱われます。
Firefox の既定の分離との違い
Firefox は Total Cookie Protection で第三者の Cookie を既定で分離しています。MDN は、互換性の高い分離 Cookie にするには、Firefox の既定の分離に頼らず CHIPS で明示的にオプトインすることを勧めています。
第三者 Cookie の現状(2026年10月時点)
第三者 Cookie の扱いは、ブラウザごとにまったく違います。
| ブラウザ | 第三者 Cookie の既定の扱い | 備考 |
|---|---|---|
| Safari (Apple) | 既定でブロック(2020 年 3 月〜) | Safari 13.1 / iOS 13.4 で全面ブロックを導入(ITP) |
| Firefox (Mozilla) | サイトごとに分離(2022 年 6 月〜、Total Cookie Protection) | Cookie の保存領域をサイトごとに分けるため、サイトをまたいだ追跡には使えない |
| Chrome (Google) | 許可(ユーザーが設定でブロック可能) | シークレットモードでは既定でブロック。廃止計画は 2025 年に取りやめ |
| Edge (Microsoft) | Chromium ベースで、独自のトラッキング防止機能を持つ | トラッキング防止に「基本」「バランス（既定）」「Strict」の3段階がある（Microsoft Learn の日本語版の表記） |
Chrome では第三者 Cookie が今も既定で使えますが、Safari と Firefox では、サイトをまたいだ Cookie の共有が既定でできません。利用者の環境を考えると、第三者 Cookie に頼らない設計を前提にするのが妥当です。
Chrome の方針転換と Privacy Sandbox の縮小
Google は 2020 年に「Chrome の第三者 Cookie を段階的に廃止する」と発表し、代替技術として Privacy Sandbox を開発してきました。廃止は何度も延期され、2025 年に計画そのものが取りやめになりました。
Chrome の第三者 Cookie をめぐる経緯
- 12020 年: 段階的な廃止を発表
代替技術として Privacy Sandbox の開発を始める。
- 22024 年 7 月: ユーザーが選ぶ方式へ
一律の廃止をやめ、ユーザーが選べる新しい方式を検討すると発表。
- 32025 年 4 月: 現行方式を維持
新しい確認画面は出さず、プライバシー設定で選ぶ今の方式を続けると発表。
- 42025 年 10 月: Privacy Sandbox の多くを終了
Topics や Protected Audience などの終了を決定。CHIPS・FedCM・Private State Tokens は継続。
何が変わったか
2025 年 4 月の発表で、Google は第三者 Cookie を選ばせる新しい確認画面は出さず、Chrome のプライバシーとセキュリティの設定でユーザーが選ぶ今の方式を続けるとしました。シークレットモードでは引き続き既定でブロックされます。
終了が決まった技術
2025 年 10 月の発表で、Topics、Protected Audience、Attribution Reporting API、Related Website Sets(requestStorageAccessFor を含む)、IP Protection、Shared Storage を含む Private Aggregation などの終了が決まりました。これらを前提にした計測や広告配信の設計は見直しが必要です。
継続する技術
CHIPS と FedCM は他のブラウザにも採用が広がったとして継続、Private State Tokens も維持されます。計測については、W3C で標準化が進む Attribution の仕様に取り組むとしています。
サイト設計への影響
Chrome での急な廃止は無くなりましたが、Safari と Firefox では既に第三者 Cookie に頼れない状況は変わりません。埋め込みは CHIPS、ログイン連携は FedCM や 1st-party のセッション、という形で第三者 Cookie に依存しない設計を進めるのが妥当です。
実務対応の優先順位
「どんな順序で対応するか」を整理します。
- 11. SameSite を明示する
ブラウザによって既定値が違うので、すべての Cookie に SameSite を書く。セッション Cookie は Lax、クロスサイトで必要なものだけ None + Secure。
- 22. クロスサイトの POST を洗い出す
外部の認証・決済から POST で戻るフローがあるか確認する。Lax の Cookie はこの POST では送られない。
- 33. 埋め込みウィジェットは Partitioned に対応
ウィジェットを提供する側なら Partitioned 属性を追加し、埋め込み先ごとに別の保存領域で動くようにする。
- 4
- 5
- 66. ブラウザ別に検証
Safari / Firefox / Chrome それぞれで動作確認する。既定値の違いで Chrome だけ動く事故を防ぐ。
ハマりやすいポイント
実装で踏みやすい落とし穴を整理します。
Secure 抜けで Cookie が保存されない
「SameSite=None」だけ書くと、Chrome と Firefox は Cookie を拒否します。Safari では保存されるため、Safari だけ動くという逆向きの差が出ることもあります。必ず Secure とセットにします。
localhost と本番で挙動が違う
HTTP のサイトは Secure 付きの Cookie を設定できませんが、MDN によると localhost では HTTPS の要件が適用されません。そのため、localhost では動くのに、HTTP の検証用ドメインでは Cookie が保存されない、といった差が出ます。検証環境も HTTPS にそろえると事故を減らせます。
サブドメイン共有 Cookie
Domain 属性を省略した Cookie は、設定したホストだけに送られます(ホスト限定 Cookie)。app.example.com と example.com で共有したいなら Domain=example.com を明示します。逆に、共有の必要がない Cookie は省略したほうが安全です。
ブラウザごとの既定値の違い
SameSite を書かない Cookie は、Chrome では Lax、Firefox と Safari では None 相当に扱われます。Firefox や Safari で検証して問題なくても、Chrome で別サイトからの POST だけ失敗する、という形で表に出ます。
Cookie の現代的なベストプラクティス
「現代の Web で Cookie をどう扱うべきか」を整理します。
セッション Cookie は HttpOnly + Secure + SameSite=Lax
ログインセッションのような重要な Cookie には、HttpOnly(JS から読めない)+ Secure(HTTPS のみ)+ SameSite=Lax(CSRF 対策)を付けます。HttpOnly により、XSS があっても Cookie の値そのものは読み出されにくくなります。詳細は JWT の正しい使い方。
第三者ウィジェット側は Partitioned 対応
埋め込みウィジェットを提供する側は、Partitioned 属性を付けて埋め込み先ごとに独立した状態を持たせます。プライバシー保護と機能の両立ができ、2025 年からは主要ブラウザすべてで使えます。
1st-party に寄せる設計
フロントと API を同じサイトに置く(BFF パターン、または example.com/api/ のような同一ドメイン)ことで、クロスサイト Cookie の問題を構造的に避けられます。
計測は 1st-party Cookie ベースで
アクセス解析や広告の効果測定は、1st-party Cookie を使う方式やサーバー側でのタグ配信を検討します。どの方式でも、Cookie や計測の内容はプライバシーポリシーで説明し、必要な地域では同意を取ります。
Cookie 周りに関するよくある質問
Q. SameSite=Lax でフォーム送信が動かなくなりました
A. 別サイトからの POST では Lax の Cookie が送られないのが原因です。同一サイト内のフォーム送信なら問題ありません。外部の決済や認証から POST で戻ってくる画面で Cookie が必要なら、その Cookie だけ SameSite=None + Secure にします。明示しない Cookie が Chrome で Lax として扱われる場合、設定から 2 分以内なら POST でも送られるため、テストでは気づきにくい点にも注意します。
Q. Chrome で SameSite=None を付けたのに Cookie が保存されません
A. Secure 属性が抜けている可能性が高いです。Chrome と Firefox は Secure の無い SameSite=None を拒否します。HTTP のページでは Secure 付きの Cookie を設定できないので、HTTPS で確認します(localhost は例外として扱われます)。
Q. Partitioned Cookie はすべての埋め込みで使うべき?
A. 埋め込みウィジェットを提供する側は対応を検討する価値があります。埋め込み先ごとにユーザー設定やログイン状態を保ちたい場合に有効です。2026年10月時点では Chrome / Edge / Firefox / Safari の最新版が対応していますが、古い Safari などでは Partitioned が無視されるので、そうした環境での動きも確認しておきます。
Q. Chrome の第三者 Cookie は結局なくならないのですか?
A. 2025 年に Google は廃止計画を取りやめ、ユーザーが設定で選ぶ現行方式を続けると発表しました。ただしシークレットモードでは既定でブロックされ、Safari と Firefox では既に制限されています。今後の方針はまた変わる可能性もあるので、Privacy Sandbox の公式サイトで最新の状況を確認してください。
Q. CSRF 対策に SameSite=Lax で十分?
A. 「大半は防げるが、CSRF トークン併用が安全」です。SameSite=Lax は別サイトからの POST を遮断するので多くの CSRF を防ぎますが、同一サイト内(サブドメインを含む)からの攻撃や、GET で状態を変える実装には効きません。CSRF トークンを併用するのが多層防御の基本です。
Q. iframe で埋め込まれた自社サイトの Cookie が落ちます
A. 自社サイトを partner.example に埋め込むと、自社の Cookie は第三者 Cookie 扱いになります。SameSite=None + Secure で送信を許可したうえで、Partitioned を付けると埋め込み先ごとに分離された保存領域で動きます。Partitioned でない第三者 Cookie は、Safari などでは既定でブロックされます。
Q. Cookie より localStorage / sessionStorage を使うべき?
A. 用途で使い分けます。サーバーと自動で共有したいもの(セッション)は Cookie、ブラウザ内だけで使うもの(UI 設定、キャッシュ)は localStorage が向いています。localStorage は JavaScript から読めるため、XSS があると中身を読まれます。認証トークンは HttpOnly Cookie に置くのが一般的です。詳しくは JWT の正しい使い方。
まとめ
Cookie の SameSite / Partitioned / 第三者 Cookie の扱いは、Web のセキュリティとプライバシー対応の土台です。
SameSite は ブラウザごとに既定値が違うので必ず明示し、クロスサイトで必要な Cookie だけ None + Secure、埋め込みウィジェットは Partitioned にする。そのうえで、フロントと API を同一サイトに置く 1st-party に寄せた設計で問題を構造的に避けるのが現実的です。Chrome は第三者 Cookie の廃止をやめましたが、Safari と Firefox では既に使えないので、第三者 Cookie に依存しない設計を進めておくのが妥当です。CORS のハマりパターン と合わせて、「Cookie が来ない / 認証が動かない」系のトラブルを構造的に減らせます。
参考リンク
- MDN: Set-Cookie(SameSite の既定値・Secure と localhost・Domain 属性・ブラウザ互換性)
- MDN: Cookies Having Independent Partitioned State (CHIPS)
- Privacy Sandbox: CHIPS
- Privacy Sandbox: Next steps for Privacy Sandbox and tracking protections in Chrome(2025年4月)
- Privacy Sandbox: Update on plans for Privacy Sandbox technologies(2025年10月)
- Google Chrome ヘルプ: サードパーティ Cookie を許可またはブロックする
- WebKit: Full Third-Party Cookie Blocking and More(2020年3月)
- Mozilla: Firefox rolls out Total Cookie Protection by default to all users worldwide
- web.dev: SameSite cookies explained