Today, WebKit partitions network state by the site of the top-level document, meaning that only subresource requests to endpoints same-site with the top-level document with include credentials. This is sufficient to achieve the privacy goals of partitioning, but it doesn't provide robust protection against security issues because it permits cross-site frames to send credentialed requests to endpoints within the top-level site, which in turn allows the exploitation of bugs such as CSRF, XSSI, or other XS-leaks. For example, if any document within a given site contains an iframe which hosts third-party content (e.g. an ad, a translation engine, or any application which sanitizes HTML but allows user-controlled frames), scripts within the iframe will be able to load resources from the first-party site which will still be served from the cache. This gives attackers the ability to exploit various cache-based XS-leaks in the top-level site. Because the key is the top-level site and not the origin, this means that any eTLD+1 with a third-party frame will remain vulnerable to information leaks: an attacker can open a pop-up to the document with the iframe and execute their attack from the frame. To fix this, consider double/triple-keying the state not just on site of the top-level document, but also on the site (or ideally, origin) of the loading document. AFAIK this matches the approach taken by Chrome: https://developers.google.com/web/updates/2020/10/http-cache-partitioning#how_will_cache_partitioning_affect_chromes_http_cache See also a related bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1681036
Thanks for filing, Artur!
<rdar://problem/74062709>