Bug 204498 – Server side HTTP Cookie in iframe is not accepted

• Status: RESOLVED
• Resolution: INVALID
• Component: Frames

[Eric]

Created attachment 384133 [details]
Simple HTML page with iframe

Hi there.

We've stumbled upon an issue with the Intelligent Tracking Prevention recently and cannot seem to find a solution for it.

One of our customers embeds our web site via an iframe into their own site. We use a simple session cookie on our site. The cookie is created server-side through the HTTP Response Header, which looks like this:

    Set-Cookie: PHPSESSID=sd7f6s76df8s7d6g9sd6g; path=/; secure; HttpOnly

But this cookie does not seem to be accepted at all when the iframe is shown and our page is loaded in it. When we check the Storage tab in the developer console in Safari, there is no cookie shown at all for the domain that is inside the iframe (our own page), only for the main domain (our customers page). One question here is if that view would show the cookie when it was partitioned by ITP or not.

This can be reproduced in a simple isolated test case. One page on domain A has a simple iframe with src on some other page on domain B which (our example page is attached). The server at domain B returns the cookie in the response header as described above. We already tried enabling the ITP debug log, but we do not find any log messages related to ITP (using Console app).

When we turn off ITP and load the iframe, the cookie is created successfully (as expected). If we turn it on again afterwards, the cookie stays and can be used, once we call the "requestStorageAccess" API successfully. But it is obviously not a viable solution to force our users to disable ITP. The user will also not have any reason to directly access our own page outside of an iframe in the case of this customer.

So, the question is: Why is the HTTP cookie that is returned in the response header not accepted/stored in the first place? Is this a bug or are we missing something?

According to the ITP documentation, the HTTP cookie should be accepted when it is marked "Secure" and "HttpOnly", which it is as shown above. Both sites run on HTTPS with valid and accepted certificates, if this makes any difference.

Details on the setup we are using to reproduce the issue:
- Mac mini with macOS Catalina (10.15.1)
- Reproducible with two Safari versions:
  - Safari 13.0.3, WebKit 15608.3.10.1.4
  - Safari Technology Preview, Release 95, 13.1, WebKit 15609.17

Please let me know if you need further details. I'll be happy to provide them.

Regards,
Eric

[John Wilander]

Hi Eric! Thanks for your report.

The case you describe is actually blocked by default by Safari and WebKit on Cocoa platforms. It's the underlying cookie policy that enforces that a website without existing cookies cannot set cookies when it is a third-party resource. This default cookie policy has been in effect for 16 years in Safari.

When you turn off ITP, you also change the cookie policy to an "accept all" policy. That's why the cookie gets accepted under that setting.

Both the default cookie policy and ITP are privacy features which explains why they both are under the same Safari setting called "Prevent cross-site tracking."

As for cookies being accepted if they are Secure and HttpOnly, that's a misunderstanding. What you are referring to is the 7-day cap on expiry of cookies set through JavaScript. If you don't want your cookies to have a 7-day lifetime, you need to set them server-side and that's where we also advise you to make sure that cookie is Secure and HttpOnly. Such cookies have much better security and privacy guarantees and are more likely to be accepted by browsers' privacy protections.

[Eric]

Thank you for your answer, Jhon. I understand we need to find a way to work without the cookie.