web-dev-qa-db-ja.com

ChromeによるSameSiteの変更に関する混乱

Chromeの新しいSameSiteの制限について説明している資料で説明が見つからないケースを理解するために助けが必要です。現在、APIに対してクロスサイトリクエストを行うサイトがホストされている場合があります。 APIはCORSヘッダーで応答します。詳細は次のとおりです。

Site: https://a.a.com
API: https://b.a.com

--API response headers

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://a.a.com

--cookie previously set with

Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly

CORSヘッダーが何かに影響を与えることは期待していませんが（SameSiteの変更について言及していないことを確認したすべてのことに基づいて）、とにかくここに配置します。このシナリオで、フラグを次のように設定した場合：

chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure

ブラウザがcookie値の送信をブロックすることを期待します。これは、CookieがSameSite = Laxを持っているかのように扱われ、これらがクロスサイトリクエストであることを期待しているためです。これは実際に発生することではなく、Cookieは正常に送信されます。これをテストするとき、すべての応答と（=有効期限が更新された）Cookieを設定して応答ごとに「Lax + POST」緩和を回避するために、すべての要求とPOST要求の間で3分間待機することも試みました。変更について何を読んでいるのか、このCookieの送信がブラウザによってブロックされない理由と、これらのリクエストが成功する理由がわかりません。

混乱を招くために、開発中に次のシナリオの場合があります。

Site: http://localhost
API: https://a.b.com

--API response headers

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost

--cookie previously set with

Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly

説明されている最初のシナリオとは異なり、これらの要求は実際にCookieが期待どおりに送信されるのをブロックします（新しいchromeフラグが有効な場合のみ）。ブラウザが表示する警告メッセージは、SameSiteおよびSecureフラグに関連しています。期待します。

誰かが最初のシナリオが機能しているのに2番目のシナリオが機能しない理由を理解するのに役立ちますか？私の懸念は、それが実際に機能するのはバグであり、機能すべきではないということです。これが事実である場合、将来、警告なしに「動作中」から「失敗」に移行する可能性があります。

Chrome変更/フラグの詳細はこちらです：

google-chromecorssame-origin-policycross-sitesamesite
5
Goblinlord

ここで述べたように https://web.dev/samesite-cookies-explained/ ：

ユーザーがwww.web.devにいて、static.web.devから画像を要求する場合、それは同じサイトの要求です。

最初のケースと同じ：

Site: https://a.a.com
API: https://b.a.com

したがって、ブラウザは最初のリクエストを同じサイトのリクエストと見なし、Cookieは削除されませんが、2番目のリクエストはクロスサイトリクエストであり、Samesite属性のないCookieは削除されます。

3
Mustapha Elbazi