SameSite Cookie の使用

<ph type="x-smartling-placeholder">

Chrome Firefox、 Edge、 IETF に沿ってデフォルトの動作が変更されている 提案、 Cookie の段階的な改善 次のように変更します。

• SameSite 属性のない Cookie は SameSite=Lax として扱われます。 つまり デフォルトの動作では Cookie がファーストパーティ コンテキストのみ。
• クロスサイト使用用の Cookie では、次のように SameSite=None; Secure を指定する必要があります。 サードパーティのコンテキストを含めることができます。

まだ実施していない場合は、 ブロックされないように設定できます。

クロスサイト Cookie またはサードパーティ Cookie のユースケース

Cookie の使用が必要な一般的なユースケースやパターンは数多くあります。 テキスト メッセージで送信されます。これらの使用方法のいずれかを提供または依存している場合 自社またはプロバイダが Cookie を 維持することです。

<iframe> 内のコンテンツ

<iframe> に表示されている別のサイトのコンテンツがサードパーティのものである 説明します。標準的なユースケースの例:

• 他のサイトから共有された埋め込みコンテンツ（動画、地図、コードサンプル、 ソーシャル投稿などです
• 外部サービスのウィジェット（お支払い、カレンダー、予約、 予約機能を利用できます。
• ソーシャル ボタンや不正防止サービスなどの、あまり目立たないウィジェット <iframes>。

ここで Cookie は、特に、セッション状態の維持、データの保存、 全般設定、統計情報の有効化、コンテンツのパーソナライズ できます。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

ウェブは本質的にコンポーズ可能なため、<iframes> は埋め込み 視聴されたコンテンツの割合を示しますサイトにあるすべての Cookie 表示される広告は、サードパーティ Cookie と見なされます。もし 他のサイトに埋め込むサイトを作成する（クッキーが必要） クロスサイト使用としてマークするか フォールバックできるようにする必要があります。

「安全でない」サイト間でのリクエスト

「安全でない」問題に思えるかもしれませんが 状態の変更を目的としています。ウェブでは、これは主に POST リクエストです。クッキー SameSite=Lax とマークされたメッセージは、 別のサイトに移動するリンクです。たとえば、<form> を POST を使用する別のサイトに Cookie が含まれていません。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

このパターンは、ユーザーをリモート サーバーにリダイレクトできるサイトに使用されます。 返す前になんらかの操作（たとえば、 サードパーティ ID プロバイダと やり取りしますユーザーがサイトを離れる前に Cookie は 単一の使用トークンを含むセット。このトークンは、このトークンを使用して 返されたリクエストをチェックして、そのエラーを クロスサイト リクエスト フォージェリ（CSRF） 防ぐことができます。返されたリクエストが POST で送信された場合、 Cookie を SameSite=None; Secure として作成します。

リモート リソース

<img> タグや <script> タグなど、ページ上のリモート リソース リクエストで送信される Cookie に依存する場合があります。一般的なユースケースは次のとおりです。 コンテンツのカスタマイズなどを行います

これは、fetch または JavaScript を使用して JavaScript から送信されるリクエストにも適用されます。 XMLHttpRequest。fetch() が credentials: 'include' オプション Cookie が含まれる可能性が高くなります。 XMLHttpRequest の場合、想定される Cookie は通常、 withCredentials 値 true 宛て。これらの Cookie は、 クロスサイト リクエストにも対応します。

WebView 内のコンテンツ

プラットフォーム固有のアプリの WebView はブラウザを使用します。デベロッパーは アプリに影響する制限や問題が 実装できます

Android では、Android のプラットフォーム固有のアプリで CookieManager API。 ヘッダーや JavaScript を使用して設定される Cookie と同様に、 クロスサイトで使用する場合は SameSite=None; Secure。

今すぐ SameSite を実装する方法

ファーストパーティのコンテキストでのみ必要な Cookie に SameSite=Lax のマークを付ける または SameSite=Strict を使用します。これらの Cookie にマークを付けない場合 デフォルトのブラウザ動作に依存して対処すれば、 ブラウザ間で一貫性がないため、ブラウザごとにコンソールの警告がトリガーされる可能性があります。 できます。

Set-Cookie: first_party_var=value; SameSite=Lax

サードパーティのコンテキストで必要な Cookie がある場合は、 SameSite=None; Secure。どちらの属性も必須です。「nginx Pod」という None に Secure が指定されていない場合、Cookie は拒否されます。差異を考慮するため ブラウザの実装では、場合によっては、緩和策を 互換性のないクライアントを処理するで説明されている戦略について説明します。

Set-Cookie: third_party_var=value; SameSite=None; Secure

互換性のないクライアントを処理する

None の追加とデフォルトの動作の更新は、引き続き 比較的新しいため、ブラウザごとに処理方法も異なります。詳しくは、 chromium.org の更新ページをご覧ください。 をご覧ください。ただし、このリストがすべてを網羅しているとは限りません。

回避策の 1 つは、各 Cookie を新しいスタイルと古いスタイルの両方で設定することです。

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

新しい動作を実装するブラウザは、SameSite で Cookie を設定します。 あります。新しい動作を実装していないブラウザでは、その値を無視して、 3pcookie-legacy Cookie含まれる Cookie を処理する際、サイトは まず新しいスタイルの Cookie が存在することを確認してから、 新しい Cookie が見つからない場合は従来の Cookie が削除されます。

次の例は、Node.js でこれを行う方法を示しています。 Express フレームワークとその cookie-parser ミドルウェア:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

この方法では、冗長な Cookie の設定や、 Cookie の設定と読み取りの両方の時点で変更されます。ただし、 動作に関係なくすべてのブラウザに対応し、サードパーティ Cookie も保持 できます。

別の方法として、ユーザー エージェント文字列を使用して、 Set-Cookie ヘッダーが送信されます。詳しくは、 互換性のないクライアントのリスト 適切なユーザー エージェント検出ライブラリを たとえば、ua-parser-js ライブラリは、 使用します。このアプローチで必要な変更は 1 つだけですが、ユーザー エージェント スニッフィングでは 影響を受けたすべてのユーザーを捕捉できるとは限りません

言語、ライブラリ、フレームワークでの SameSite=None のサポート

ほとんどの言語とライブラリでは、SameSite 属性がサポートされています。 できます。ただし、SameSite=None の追加はまだ比較的小さいため、 現時点では、標準的な動作の回避策が必要になることがあります。 これらの動作については、 GitHub の SameSite サンプル リポジトリ。

困ったときは

Cookie はウェブのいたるところで使用されるため、開発チームにとってはめったにありません。 どこで設定、使用されているか（特に クロスサイトのユースケースで 最適です問題が発生した際、 ぜひご連絡ください。

• 問題を報告する GitHub の SameSite サンプル リポジトリ。
• 質問を投稿してください。 「samesite」（StackOverflow のタグ）。
• Chromium の動作に関する問題については、 Chromium の Issue Tracker
• で Chrome の進捗状況を確認する SameSite の更新ページ。