CODEWITHSUNDEEP
cookiesiframesamesitethird-party-cookies
Tobia
Tobia

Reputation: 9526

How Samesite cookie settings works with iframes

I have to embed a page with iframe to a different domain page. enter image description here

This iframe is loaded with a jwt token that authenticates the user in domain B.

This response, creates a session cookie and reloads the page (from domain B to domain B page) of the iframe.

This process works for Firefox, but doesn't work for Chrome because the setcookie is refused due to SameSite settings.

Probably I did not understand the SameSite settings because the authentication happened starting from domain B to domain B so I cannot understand why SameSite Lax is not valid for Chrome.

Upvotes: 0

Views: 273

Answers (1)

Heiko Theißen
Heiko Theißen

Reputation: 17487

Browsers employ two mechanisms to deny a page from domain B access to its cookies when it is embedded (iframed) within a page from domain A, if A and B are from different sites, for example, A = example.com and B = myapp.org.

The first mechanism has been in force for a few years: To be accessible, the cookie must have SameSite=None. The SameSite cookie attribute is not only evaluated during page embeddings, but also during navigation from a page from A to a page from B. For navigation, SameSite=Lax would be sufficient, but what blocks you is the embedding, not the navigation.

The second mechanism is much more far-reaching, since it does not depend on an attribute like SameSite (which the server controls), but is controlled by the browser alone: third-party cookie blocking. This is currently being rolled out by Chrome (and other browser vendors, though perhaps not yet Firefox) under the "privacy protection" headline.

Privacy-preserving alternatives to third-party cookies are partitioned cookies (which are valid in one embedding, but not across embeddings) and the storage access API (whereby the user is prompted to grant access to the third-party cookies).

Upvotes: 2

Related Questions