Skip to content

Instantly share code, notes, and snippets.

@iansltx

iansltx/_safari-iframe-cookie-workaround.md

Last active July 30, 2024 14:53
Show Gist options
  • Save iansltx/18caf551baaa60b79206 to your computer and use it in GitHub Desktop.
Save iansltx/18caf551baaa60b79206 to your computer and use it in GitHub Desktop.
Download ZIP
Safari iframe cookie workaround
Raw
_safari-iframe-cookie-workaround.md

Safari iframe cookie workaround

Safari by default discards cookies set in an iframe unless the host that's serving the iframe has set a cookie before, outside the iframe. Safari is the only browser that does this.

The 10k foot view

In order to get around the issue, the parent (src) and child/iframed/remote (dest) site have to work together, if the source site only wants users to access the destination via the iframe and can't assume that the user has visited the destination host before.

Normally, a user would navigate from page A, with no external iframe, to page B, with an external iframe, by clicking a direct link between the two. To make the workaround work, the link from page A is instead a "bounce" URL on the destination site, which sets a cookie (no requirements on name, value, etc.) and redirects back to page B. The redirect can be hard-coded for security, or left more open.

The warning

The following files are a naive example of the problem/solution. You'll want to think through your solution more carefully...don't copy-paste these snippets into a production setting! I haven't thought through the security ramifications of what's shown here...which means that there are some, and they aren't good. You've been warned.

The implementation details

This gist includes an implementation of both source and destination sides of the above workaround, including a test to make sure that it actually works. To see the fix in action, place src.php on one host, dest_xxx.php on another, then edit lines 2 and 3 on src.php to reference where those files show up.

To see the Safari problem without the solution, on a new Safari browser, navigate to src.php?redirected=true on a "clean" Safari. By "clean" we mean that Safari has never had a cookie (successfully) set by the destination domain before. The easiest way to do this is to fire up a Safari-powered instance on BrowserStack or the like.

When you load the page, you'll get an iframe. Click the link inside the iframe and you'll be greeted with a "Cookie not set!" message.

To see the solution, navigate to src.php (without the query string parameter) in the same browser (since the cookie wasn't successfully set, there's no need to set up a new clean Safari instance, though you can if you like). Then click the "Bounce here..." link. The browser will hit the remote site, which will set a blank cookie and redirect back to src.php?redirected=true.

When you click the link inside the iframe this time, you'll get "Cookies match!".

Note that if you use some browser (Chrome, Firefox, IE) other than Safari, you can just hit src.php?redirected=true and get "Cookies match!" without having to first go through the redirect.

The credits

This issue was discovered, and its solution devised, while working on Parking Mobility (https://parkingmobility.com).

Raw
dest_bounce.php
<?php
header("Location: " . $_GET['redirect']);
setcookie("__trust");
Raw
dest_get.php
<?php
if (!isset($_COOKIE['testcookie']))
echo "Cookie not set!";
else if ($_COOKIE['testcookie'] != $_GET['cookie'])
echo "Cookies don't match: " . $_COOKIE['testcookie'] . ' != ' . $_GET['cookie'];
else
echo "Cookies match!";
Raw
dest_set.php
<?php
$value = uniqid();
setcookie("testcookie", $value);
echo "<p>Now go <a href='dest_get.php?cookie=" . $value . "'>here</a></p>";
Raw
src.php
<?php
$internalPath = "http://local.test/path";
$externalPath = "http://remote.test/path";
?>
<html><head><title>Redirect Cookie Test</title></head>
<body>
<?php if ($_GET['redirected']): ?>
<p>iframe starts below...</p>
<iframe src="<?= $externalPath ?>/dest_set.php"?>
<?php else: ?>
<a href="<?= $externalPath ?>/dest_bounce.php?redirect=<?= $internalPath ?>/src.php?redirected=true">Bounce here...</a>
<?php endif; ?>
</body>
@jhud
Copy link

jhud commented Sep 10, 2020 •
edited
Loading

I looked at some existing solutions, and big companies which rely on iframes appear to be passing the session tokens through PostMessage between the host page and the iframe.

But I am sick of doing these increasingly ugly hacks. IMO, iframes and 3rd party cookies are dead - Apple has just killed them a year or so earlier.

So I have converted my old iframe integrations to use my existing app REST API + JavaScript + local storage. My customers love this JS client-side integration compared to iframes, and it gives me a unified interface for my apps and web. It's a much more solid solution which will last for the ages.

I know you don't want to hear this if you are looking for a quick fix, but I suggest that you already start planning to ditch iframes + 3rd party cookies in the medium to long term.

@code2infiniteE
Copy link

Thanks for the many ideas in this thread!
Wanted to share we've been using a service to get around this issue and so far it has been working well for us: cloudcookie.io. We host content in 3rd party iframes and often don't have access to the parent (host) page. It's a commercial solution so might not be appropriate for all but pretty inexpensive (and has a free tier).

Hi, i double checked everything but we have a PHP App and need a Session Cookie and this Javascript "CloudCookie" will not be able to pass Session Cookie to PHP, or am i mistaken? My Mate told me this would be not fit my needs. :-S

I also tried cloudcookie.io and have it working on a project. It's a front-end (javascript) cookie framework, so if you need the cookies on the server-side (eg PHP), you just need to add an ajax call or page redirect once you get the cookies from the front-end. (@lenusch)

@Benamin
Copy link

Benamin commented Sep 17, 2020 •
edited
Loading

this solution is works; https://github.com/vitr/safari-cookie-in-iframe/blob/master/index-fixed.html

@sparkdoo
Copy link

So I have converted my old iframe integrations to use my existing app REST API + JavaScript + local storage. My customers love this JS client-side integration compared to iframes, and it gives me a unified interface for my apps and web. It's a much more solid solution which will last for the ages.

@jhud how are you dealing with the security implications of providing a client side javascript approach vs iframe? We considered both options but found the risk of running our javascript next to potentially malicious javascript too much of a concern to proceed, but of course as you say the new concern is that our existing solution will be completely blocked in the not so distant future

@Tofandel
Copy link

The joys of tech giants imposing their wishes to everybody because they are trying to block third party tracking, except third party tracking can find tons of workaround other than cookies usually, but for authenticating a user in a secure way you need cookies, so effectively they screw you, force you to use a thousand times less secure approach for the sake of user privacy and don't give you an alternative

Iframes are not just used for third party tracking and sadly they don't understand that.

@jhud
Copy link

jhud commented Aug 31, 2021

So I have converted my old iframe integrations to use my existing app REST API + JavaScript + local storage. My customers love this JS client-side integration compared to iframes, and it gives me a unified interface for my apps and web. It's a much more solid solution which will last for the ages.

@jhud how are you dealing with the security implications of providing a client side javascript approach vs iframe? We considered both options but found the risk of running our javascript next to potentially malicious javascript too much of a concern to proceed, but of course as you say the new concern is that our existing solution will be completely blocked in the not so distant future

I trust all the host websites. I would love to have better integration to avoid CSRF/XSS attacks, but it is sufficient for my customers' purposes, and it is the situation the tech vendors have left us in.

The approach is basically to write a Single Page Application. After having done React and Vue.js development since making this decision, it has just cemented my opinion that client-side JS is the way to go for anything other than a basic CRUD website.

@gbenchanoch
Copy link

Thanks for the many ideas in this thread!

Wanted to share we've been using a service to get around this issue and so far it has been working well for us: cloudcookie.io. We host content in 3rd party iframes and often don't have access to the parent (host) page. It's a commercial solution so might not be appropriate for all but pretty inexpensive (and has a free tier).

Are you still using CloudCookie? Has the solution been stable for you across all browsers, as well as mobile? I am having stability issues loading a specific 3rd party provider via iframe, particularly on Safari.

@pini85
Copy link

pini85 commented Oct 14, 2021 •
edited
Loading

Thanks for the many ideas in this thread!

Wanted to share we've been using a service to get around this issue and so far it has been working well for us: cloudcookie.io. We host content in 3rd party iframes and often don't have access to the parent (host) page. It's a commercial solution so might not be appropriate for all but pretty inexpensive (and has a free tier).

I would also be interested to know if this is still valid

@code2infiniteE
Copy link

@pini85 && @gbenchanoch yes cloudcookie.io has been working for us so far! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment