Safari Web Extension background request CORS issues

Hi,
I am trying the new Safari WebExtension on Safari 14 beta on Majove, everything seems smooth so far except one thing:
The ajax request in the background will always fail since it is cross origin.
Here is the error image

This is not an issue on Chrome, and I think it make sense because the Web Extension background page's Origin is always the WebExtension protocol(like "chrome://<uuid>"), and should approve all the request even if the origin mismatch

But in Safari WebExtension it is not allowed. Even if I add the "Access-Control-Allow-Origin: *" header in the server's response header, the background page requests still fails.

The only way I can make it working is to disable the cross origin restrictions in the Develop menu, but that is not a solution for production.

Any advice to resolve this?
Thanks a lot

Accepted Reply

CORS requests are ignored in Safari in the background and pop up pages if the extension has those domains in their manifest permissions. Note that CORS is enforced for content scripts, which matches a change Chrome is also making soon.

Also note, the GUID for Safari web extensions changes every launch of Safari to avoid website fingerprinting.

Replies

Can you send a feedback report via Feedback Assistant with a test extension? Thanks!
Hi @timothy,
I re-tested my extension, actually it is my server issue, after I added the following headers in response

Access-Control-Allow-Origin: safari-web-extension://<guid>
Access-Control-Allow-Headers: <some request header we sent>

Safari background page makes the requests successfully.

However, this is still something extension developers may concerns about, should Safari check the CORS in the extension background page? I feel that the background page is not a normal webpage, extension developers may make API requests to the servers out of their control, if this CORS limit is applied, then a lot of the background requests will fail because of this web-extension protocol Origin

Compared with Chrome and Firefox, these browsers always approve the CORS request even if the origin mismatch.

Just would like to know if Apple have any plan remove this CORS limit in background page.

Thanks a lot

CORS requests are ignored in Safari in the background and pop up pages if the extension has those domains in their manifest permissions. Note that CORS is enforced for content scripts, which matches a change Chrome is also making soon.

Also note, the GUID for Safari web extensions changes every launch of Safari to avoid website fingerprinting.
What I mean, is CORS requests are allowed in the background and pop up pages if the extension has those domains in their manifest permissions.
Thanks a lot @timothy for pointing out all these
Yes, I added the URL to manifest permission (it seems the wild cards url https://*/ has no effect on unblocking CORS), and the CORS request works fine in the background.
Thank you for the help!

Hello luxu, I have been facing with same CORS issue with my web extension. Can you share what URL permission was added to the manifest? This would help me try the same.

Hello luxu, I have been facing with same CORS issue with my web extension. Can you share what URL permission was added to the manifest? This would help me try the same.

luxu/swaminathanv, did you guys ever find working solution? I'm now trying on manifest 3 and trying this approach with host_permissions without success.

Add a Comment

I am currently having the issue in Manifest v3 (In Manifest v2 everything works fine)

In my manifest I have this:

"host_permissions": [
        "*://example.com/*"
    ]

When I do fetch("https://example.com") in background.js I get these errors:

[Error] Fetch API cannot load https://example.com/ due to access control checks.
[Error] Failed to load resource: Origin safari-web-extension://e0b5d7c7-c079-484b-8825-44d261383cb6 is not allowed by Access-Control-Allow-Origin. Status code: 200 (example.com, line 0)

Is there a way to avoid CORS issues without altering server access control settings?

My Stackoverflow questions: https://stackoverflow.com/questions/73712933/cors-issue-during-http-request-from-background-service-worker-in-safari-web-exte

Link to GitHub repo with the project to reproduce the issue: https://github.com/nick-kadutskyi/safari-ext-cors-issue

Additional link to download project files to reproduce the issue: https://web.tresorit.com/l/DKcJu#83UK96xDiX0g9P35gehUsw

To test the issue:

  1. Allow Unsighned Extensions in Safari > Develop menu item
  2. Run the project in Xcode
  3. Once extension is installed open console for background page Develop → Web Extension Background Pages → Test CORS Issue Extension - Service Worker
  4. In main window navigate to https://example.com (you will need to allow the extension to access this domain via action button) or click action button in a toolbar (both actions will trigger fetch function in background script)

Update 1:

The workaround for now to use background scripts (deprecated in Manifest v3) instead of background service worker.

Instead of this:

"background": {
        "service_worker": "background.js"
    },

Do this:

 "background": {
        "scripts": ["background.js"]
    },
  • Thank you so much, I was going nuts trying to figure out what was wrong and this did the trick!!

    "background": { "scripts": ["background.js"] }, but wouldn't they reject this from being approved because as you said the background scripts is deprecated in Manifest v3?

Add a Comment

Disappointing, but the fix of switching from service_worker to the background script worked for our extension as well. Otherwise we get CORS issues. This seems like a bug in Safari with its service_worker implementation in Manifest v3.

Also note, the GUID for Safari web extensions changes every launch of Safari to avoid website fingerprinting.

If this is true, then how are you supposed to add a Safari extension to an Access-Control-Allow-Origin header? We'd like our extension to be able to POST data but it needs to be added to the header for CORS. We don't want to add safari-web-extension://* because that seems to be opening us up for cross-origin attacks from other extensions (unlikely, but you never know)