Safari, iFrames, and CORS
youraerials opened this issue · comments
Hi and thanks for creating itty-cors!
There is a new issue in Safari and Safari based browsers (e.g. everything on iPhones) where Safari's preflight check attempts to match the Origin to the URL making the request, EVEN if that request is coming from an iFrame. So when a page a AAA.net embeds an iFrame at BBB.org, Safari as of September 2023 now insists that the CORS headers coming back to request coming from BBB.org have an Access-Control-Allow-Origin header allowing not BBB.org but AAA.net. For us, in practice this has meant that we just have to allow * or be broken in Safari.
In itty-cors, when we set Origin: ['*'] in the config, that isn't what we get in the Header. Line 33 does this:
allowOrigin = (origins.includes(origin) || origins.includes('*')) && { 'Access-Control-Allow-Origin': origin }
meaning that I will get the Origin domain written into the header, not the literal "*"
When this happens, in the case of an iFrame request, it fails preflight in Safari and so breaks.
Can you just return the intact header "Access-Control-Allow-Origin": "*" for cases where the setting is "Origin: ['*']" or in the default case where nothing is set?
So, the terribly [late] answer is that:
The built-in cors in itty-router v5.x does fully support a '*' origin, and will only reflect the origin (as you're seeing) under specific circumstances, that line up with the behavior of industry standards (express.js).
I highly recommend following the migration guide here, (and likely switching over to AutoRouter to save a bunch of code as well).
https://itty.dev/itty-router/migrations/v4-v5