Safari prevents CloudFront signed cookies from being transmitted to the server when the web application lives inside an iframe belonging to another domain. I understand browsers are securing against malicious third-party cookies, but how is an HTTPS cookie a threat? See references to this issue: https://github.com/awslabs/unicornflix/issues/15 (long discussion with several developers facing this issue) https://stackoverflow.com/questions/66445271/aws-signed-cookies-in-an-iframe As far as I know, Chrome & Firefox do not prevent CloudFront signed cookies from being transmitted to the CloudFront distribution server.
Hi! Thanks for filing! (In reply to sam from comment #0) > Safari prevents CloudFront signed cookies from being transmitted to the > server when the web application lives inside an iframe belonging to another > domain. > > I understand browsers are securing against malicious third-party cookies, > but how is an HTTPS cookie a threat? WebKit's tracking prevention has full third-party cookie blocking since spring 2020: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ The fact that a cookie is set to secure doesn't limit its capability to be used in cross-site tracking. What you should be using is the Storage Access API. See "How To Use the Storage Access API" in https://webkit.org/blog/11545/updates-to-the-storage-access-api/. > See references to this issue: > > https://github.com/awslabs/unicornflix/issues/15 (long discussion with > several developers facing this issue) > https://stackoverflow.com/questions/66445271/aws-signed-cookies-in-an-iframe > > > As far as I know, Chrome & Firefox do not prevent CloudFront signed cookies > from being transmitted to the CloudFront distribution server. Chrome still has no third-party cookie blocking at all by default, unless you count SameSite cookies. However, Chrome blocks third-party cookies in incognito mode IIRC and the Chrome team has announced that they'll move to third-party cookie blocking or partitioning by late 2023. Firefox has list-based third-party cookie blocking by default and full third-party cookie blocking in private browsing mode IIRC. My understanding is that they are working as quickly as possible toward third-party cookie blocking or partitioning by default. Safari is indeed leading in this space but you should expect third-party cookies to be blocked in all modern browsers within a couple of years. Again, checkout the Storage Access API. It's built for use cases like yours.
Hey John, Thanks for the detailed reply! I wish Storage Access API would work in this case, but AWS CloudFront expects GET requests to contain a "Cookie" header containing these cookies: - CloudFront-Policy - CloudFront-Key-Pair-Id - CloudFront-Signature And those are set as HTTPS cookies by an initial API call that returns those cookies via three "Set-Cookie" headers. If I missed something and there's some way to pull this off using Storage Access API, please let me know. Otherwise, it looks like this important security feature of AWS will no longer work in iframed web apps.
(In reply to sam from comment #2) > Hey John, > > Thanks for the detailed reply! > > I wish Storage Access API would work in this case, but AWS CloudFront > expects GET requests to contain a "Cookie" header containing these cookies: > > - CloudFront-Policy > - CloudFront-Key-Pair-Id > - CloudFront-Signature > > And those are set as HTTPS cookies by an initial API call that returns those > cookies via three "Set-Cookie" headers. > > If I missed something and there's some way to pull this off using Storage > Access API, please let me know. Otherwise, it looks like this important > security feature of AWS will no longer work in iframed web apps. The Storage Access API covers all types of cookies – setting and sending in HTTP, as well as setting and reading through document.cookie. I don’t understand in what way the Storage Access API would not work for you. Did you read the how-to guide?
My mistake, I missed a few points. I'll dive into it deeper when I get a chance. Thanks again!