Could you please elaborate the steps to reproduce the issue from TE end.

Thanks..

I have an extension that loads on linkedin pages. When it tries to sends a request in 56 it gets blocked by CORS. With further investigation I found Chrome is now sending a different origin than before. Its using the origin header "linkedin.com" instead of "chrome-extension://...". However, CORS is still expecting "chrome-extension://...". This puts your backend in a very hard position because it has to know linkedin.com should be translated to chrome-extension://. Normally you just echo back the origin for CORS.

So to reproduce you have to have an extension that sends ajax requests from a web page. I'm using "content_scripts" to load my js on those linkedin pages. I'm also using angular 1 $http to send ajax requests. When you send the request you should notice the origin header has changed in 55 vs 56.

Deleted: chrome_2017-01-19_15-16-36.png 21.4 KB

	chrome_2017-01-19_15-16-36.png 21.4 KB View Download

What does "load an extension on linkedin.com" mean? Do you mean clicking the page action button when on linkedin.com (as an extension running in the background has no association with a specific website)?

If so, is it possible that your extension simply injects JS into page (which is then executed in the context of that page) rather than making the request itself?

My extensions injects itself on linkedin pages using "content_scripts". See: https://developer.chrome.com/extensions/content_scripts

So yes JS is injected into the page automatically. However, Chrome sandboxes that JS normally and JS from the page can not interact directly with JS injected by an extension.

Previously because of this sandboxing  ajax requests received the origin of the extension. Now they are getting the origin of the page. This is not too much of a problem; however, the expected Access-Control-Allow-Origin header still needs to reference the extension origin and not the page origin.

So to reproduce you need to have an extension that injects itself onto a page. It then needs to make a an ajax request.  You should see a difference in the request Origin header between Chrome 55 and 56.

Got it.

+ericdingle@ PTAL. Has something changed in the security model of extensions?

I reproduced this with BrowserStack, making sure all other extensions were removed. I could see two possibilities. #1 Chrome 56 changed how injected extensions report their origin. #2 Angular 1.5.X has is injecting its own wrong Origin header with 56.

I don't think Angular even adds an Origin header. I'm guessing that is done by the browser?

So if #1 is true is this and intended behavior? If so I think it is wrong. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

The allow origin header can be * or the origin. So server side you need some indication of the correct origin.

Looking at other extensions I noticed one that manually injects a header: "x-cross-domain-origin": "https://mail.google.com"

I'm guessing they had a similar problem and thus they added a custom header to get the server to respond correctly.

So maybe this is a common problem that happened in the past and I'm only seeing it now on my extension?

This looks similar to  bug 680320  which was a recent regression.

paul.m.bailey@: Can you still reproduce it with the latest canary version?  

I originally saw the bug with a user on Chrome 56 and then reproduced it on 56 dev on browserstack. Is that good enough or should I reproduce again?

Browserstack has version 56.0.2924.14 does that have the fix applied?

Your original report mentions Chrome 56 stable but 56 stable hasn't been released yet, so I wanted to make sure that we are looking at the same version. The bug I pointed to is also fixed around the same time as your report (and if you have a minimal repro case, that would be great too).

This was the version of the user who encountered the bug first: 56.0.2924.67 (Official Build) beta (64-bit)

No, it looks like the merged fix landed after 56.0.2924.14 (fix is at revision #444328 whereas 56.0.2924.14 is at #433059) 

Duping into  bug 680320 .

paul.m.bailey@: Please let us know if you still see the problem with a version newer than 56.0.2924.67.

OK I verified the correct origin is being sent. Version is 56.0.2924.87 (64-bit).