Why is the background script setting header origin:chrome-extension://myextensionid?

[Eric]

I'm in the process of moving content script calls to the background.js because of chrome 73 CORB changes.

The problem I've noticed is that any call from the background sets Origin: chrome-extension://mychromeId and is rejected from the servers.

The domain is listed in the permissions area of manifest

I've tried setting the origin header via chrome.webRequest.onBeforeSendHeaders.addListener but the origin header doesn't show up.

This problem wasn't an issue calling from the content scripts.  I have transitioned to the fetch api in the background.js vs XMLHttpRequest.

Any ideas why?  Thanks for the help!

[Dave Teare]

This is normal and is a feature imo. We have some servers with strict CORS settings and we rely on Chrome setting this origin to a trusted value to allow us to loosen things up for our extensions while keeping things locked down for others. If `chrome.webRequest.onBeforeSendHeaders` allowed you to override this header then extensions could get around restricted CORS configurations, which would be a security concern.

Are your `fetch` requests going to a server that you control? What error does `fetch` report?

++dave;

[Eric]

Fetch requests are not going to a server\domain we control.  The domain is listed in the permission manifest so I would think that requests to that domain should be allowed and not put the chrome id in the origin header.  That's one of the greatest strengths of an extension.

Fetch requests are returning unauthorized.  

[Andrew]

probably the server you don't control is rejecting it because its not set up to accept from your chrome extension.

Have a look at the Response Header coming from that server and look for the "Content Security Policy" being returned.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/fe8f4e1e-f970-4baa-8601-721dd72a0530%40chromium.org.

[Simeon Vincent]

To my knowledge the intended functionality is that Chrome will not send an Origin header for most HTTP methods if the extension has host permissions for the target domain. The only exception to that is POST as (I believe) the HTTP spec requires an origin on post for some reason I honestly don't quite understand. If you don't have host permissions, the chrome-extension origin should be included.

Simeon - @dotproto

Extensions Developer Advocate

On Friday, August 9, 2019 at 4:29:07 PM UTC-7, Andrew wrote:

probably the server you don't control is rejecting it because its not set up to accept from your chrome extension.

Have a look at the Response Header coming from that server and look for the "Content Security Policy" being returned.

On Fri, Aug 9, 2019 at 4:40 PM Eric wrote:

Fetch requests are not going to a server\domain we control.  The domain is listed in the permission manifest so I would think that requests to that domain should be allowed and not put the chrome id in the origin header.  That's one of the greatest strengths of an extension.

Fetch requests are returning unauthorized.  

On Friday, August 9, 2019 at 7:49:47 AM UTC-7, Dave Teare wrote:

This is normal and is a feature imo. We have some servers with strict CORS settings and we rely on Chrome setting this origin to a trusted value to allow us to loosen things up for our extensions while keeping things locked down for others. If `chrome.webRequest.onBeforeSendHeaders` allowed you to override this header then extensions could get around restricted CORS configurations, which would be a security concern.

Are your `fetch` requests going to a server that you control? What error does `fetch` report?

++dave;

On Thursday, August 8, 2019 at 3:03:36 PM UTC-4, Eric wrote:

I'm in the process of moving content script calls to the background.js because of chrome 73 CORB changes.

The problem I've noticed is that any call from the background sets Origin: chrome-extension://mychromeId and is rejected from the servers.

The domain is listed in the permissions area of manifest

I've tried setting the origin header via chrome.webRequest.onBeforeSendHeaders.addListener but the origin header doesn't show up.

This problem wasn't an issue calling from the content scripts.  I have transitioned to the fetch api in the background.js vs XMLHttpRequest.

Any ideas why?  Thanks for the help!

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[Eric]

Hi Simeon,

Appreciate the help.  I'm assuming by host permissions you mean the domain is listed in the manifest permissions area.  

I can confirm from the background.js any POST regardless of manifest permissions include origin:chrome-extension://myextensionid.  There's a workaround by using onBeforeSendHeaders to modify the headers and set the correct origin.

My concern is with manifest v3 coming out will this workaround be going away?  Can we still modify origin headers in manifest v3?

[Simeon Vincent]

Hey, sorry for the delay; I was at a conference last week.

Yeah, I meant permissions for a specific site. Today they're part of the "permissions" or "optional_permissions" arrays, but in MV3 there will be a dedicated "host_permissions" array for them. But that's getting off into the weeds.

While declarativeNetRequest does not currently support Origin modification, it seems that we're planning use the target origin if the extension has host permissions as per comment 17 on issue 966223. If you'd like to see more general Origin header modification, I'd recommend opening a new issue on https://crbug.com to request a new condition/action for the declarativeNetRequest API. 

Simeon - @dotproto

Extensions Developer Advocate