Causes issue with Access-Control-Allow-Origin:*

[danielchatfield]

Browser: chrome
Example (may be fixed soon though Fixed by using https directly): http://yeoman.io/community-generators.html

Page tries to load http://yeoman-generator-list.herokuapp.com/ which results in: XMLHttpRequest cannot load http://yeoman-generator-list.herokuapp.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://yeoman.io' is therefore not allowed access..

If the page requests the https version directly then it works.

[diracdeltas]

Wow, what an interesting bug! Both http://yeoman-generator-list.herokuapp.com/ and https://yeoman-generator-list.herokuapp.com/ send "Access-Control-Allow-Origin:*", so in theory CORS should allow http://yeoman.io to load either by XMLHttpRequest.

But in reality:

> $.get('http://yeoman-generator-list.herokuapp.com');  // returns 404 and "XMLHttpRequest cannot load http://yeoman-generator-list.herokuapp.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://yeoman.io' is therefore not allowed access."
> $.get('https://yeoman-generator-list.herokuapp.com');  // returns 200, no errors

And indeed, disabling the Heroku rule makes both work fine. The behavior is exactly the same in Firefox 26.

My guess is that the browser tries to check cross origin request rules on XMLHttpRequest.send() per http://www.w3.org/TR/XMLHttpRequest/#cross-origin-request-event-rules and gets confused because the URL it's supposed to load never gets loaded. So it returns an error, which Chrome mistakes for a cross origin resource sharing failure.

If that's the case, we need to detect when an HTTP XMLHttpRequest is opened, abort it, and then open and send a new XMLHttpRequest with the rewritten URL. :/

[danielchatfield]

This also causes several analytics services to fail, e.g. mixpanel.

[riking]

Bump - this is causing issues with Discourse on a CDN.

https://github.com/discourse/discourse

Test case: http://forum.fazedores.com/

[Akamaozu]

@diracdeltas Your explanation seems to hit the nail on the head.

Was having trouble with xmlhttp not getting the access-control-allow-origin header I clearly set. Requesting from my custom domain worked perfectly but the Heroku domain resulted in CORS. I suspect its something to do with the redirect because that's the only thing that changed.

[emas80]

Hi, we are experiencing the same issue on our beta environment, with the Firefox version.

On our beta environment, we don't have https enabled, so you are browsing in http and contacting our different services only in http.

The front end is a Rails app hosted on Heroku, the assets are hosted on S3. CORS on S3 is correctly configured as for their guide. If I disable HTTPs everywhere it works perfectly.
Also, Mixpanel fails, as I can see in the JS console some CORS-related errors about some urls being contacted from Mixpanel javascript. Mixpanel, like other tools, uses https if it founds https in the url, http otherwise.

It's really weird because from the files hosted on S3, the javascripts are loaded, while the .css are blocked. Needless to say that all of them are hosted on S3 in the same bucket.

Please note that on our production environment, where https is enabled for every service, everything works perfectly, and I can't see any single error, not even in Mixpanel javascript.

[jsha]

From @diracdeltas' summary it sounds like the short-term fix might be to simply skip rewrites of XHRs for now. If the parent page is HTTPS, the XHR should already go to HTTPS or it will be blocked as active mixed content (https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl). If the parent page is HTTP we aren't improving security a lot by rewriting the XHR.

[jsha]

@emas80 While we're working on a fix, you may be able to fix the issue in your dev environment by changing your code to always contact the HTTPS version of s3, even if you are running in non-HTTPS dev environment.

[garrettr]

From @diracdeltas' summary it sounds like the short-term fix might be to simply skip rewrites of XHRs for now.

XHRs aren't the only type of request affected by this bug. For example, if you load the test case from #49 (comment), you can see that CORS errors are firing for web fonts (.woff and .ttf). This suggests an interaction between HTTPS everywhere and the CORS implementation in Firefox, I would expect the other content types listed on this page will have issues too.

[emas80]

OK thanks!

On Tue, Nov 25, 2014 at 3:21 AM, jsha notifications@github.com wrote:

@emas80 https://github.com/emas80 While we're working on a fix, you may
be able to fix the issue in your dev environment by changing your code to
always contact the HTTPS version of s3, even if you are running in
non-HTTPS dev environment.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

[garrettr]

@cooperq pointed out that this bug is present in both Firefox and Chrome, so it's likely not implementation-specific, but is more likely, as Yan suggested in #49 (comment), something related to the spec. I was able to avoid the issue by returning early instead of rewriting the URLs that are failing due to CORS.

Interestingly, I was able to determine (by setting breakpoints in the Firefox addon code) that Firefox attempts to rewrite the Fastly font URLs to use https, but the CORS error message refers to the original URL with http.

[diracdeltas]

anne van kesteren says this Firefox bug might be relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=881830

[diracdeltas]

Bug in chrome: https://code.google.com/p/chromium/issues/detail?id=387198

[diracdeltas]

https://bugzilla.mozilla.org/show_bug.cgi?id=881830#c12 seems like the right explanation here. When a subresource is redirected to HTTPS by HTTPS-E or HSTS, the browser says, "I have no CORS information for this new URL, so just block it."

Did a quick test and this seems to be fixed in Chrome but not in Firefox. To repro, make sure you have the Heroku rule enabled in the dev version of HTTPS Everywhere Firefox, then do an XHR to http://yeoman-generator-list.herokuapp.com/ in the context of an HTTP page at a different origin. In Firefox 36, the XHR silently fails. OTOH, https://yeoman-generator-list.herokuapp.com/ loads fine.

[SimonSapin]

That Firefox bug is marked as fixed in Firefox 38, but I can reproduce #1365 (which I think is a case of this bug) on Firefox Nightly 40.0a1 (2015-04-04)

[AnAkkk]

I still have the same issue with Firefox 39.

[AnAkkk]

Is there any progress on this? I can't enable https everywhere because I have this issue on one of the websites I often visit.

[jsha]

No progress so far, I'm afraid. In the meantime, if you would like to use HTTPS Everywhere, you can disable the rules for the specific site that has problems using the icon menu.

[swrobel]

I get the same issue on http://js2.coffee using Firefox 43.0.2 & HTTPS-Everywhere 5.1.2 on a Mac. I do not have the same issue on Chrome 47 & HTTPS-Everywhere 2015.12.16. The Firefox console shows the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://code.ionicframework.com/ionicons/2.0.1/fonts/ionicons.woff?v=2.0.1. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

Checking the headers of both http://code.ionicframework.com/ionicons/2.0.1/fonts/ionicons.woff?v=2.0.1 and https://code.ionicframework.com/ionicons/2.0.1/fonts/ionicons.woff?v=2.0.1 reveals that they include Access-Control-Allow-Origin:* as expected.

[chojrak11]

I'm bumping this with problem on www.easyjet.com. The button "Check-in Online" doesn't work when HTTPS Everywhere is installed/enabled in Firefox. Version 46.0beta8, HTTPS Everwhere 5.1.6. The error message in Firefox console is:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.easyjet.com/ejcms/nocache/jsCallbacks/CheckInCallback.aspx?qs=&scLang=pl-PL&sender=. (Reason: CORS header Access-Control-Allow-Origin missing)

[mbergin]

Seeing this in 2016.9.1 in Chrome 52.0.2743.116 which breaks the flight search form:

XMLHttpRequest cannot load https://www.easyjet.com/ejcms/cache15m/api/flights/search?AdminFeePerBookin…,NTE,NCE,TLS,AJA,BIA,FSC,CDG,ORY,SXF&MaxResults=4&PreferredOriginIatas=LGW. Credentials flag is 'true', but the 'Access-Control-Allow-Credentials' header is ''. It must be 'true' to allow credentials. Origin 'http://www.easyjet.com' is therefore not allowed access.

[mayhemer]

Regarding Firefox, I filed a Mozilla bug to add an API to support HTTP->HTTPS redirects, that would not be blocked by CORS checks, invoked by an XPCOM API directly on http channels. I never got a feedback from Yan in our bugzilla, tho.

Bumping here then, since the issue still exists. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1149250#c3 for suggested changes in Gecko and give a feedback here or there please. We want to move forward. Thanks.

[herrernst]

This is now fixed in upcoming Firefox 59 with "upgradeToSecure", see https://bugzilla.mozilla.org/show_bug.cgi?id=1149250

Would be good if HTTPS Everywhere would use it in the future to reduce breakage

[jeremyn]

It seems like from https://bugzilla.mozilla.org/show_bug.cgi?id=1149250 and https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/BlockingResponse that there is a new option in Firefox that allows some http-to-https rewrites to bypass CORS checks, which would let us avoid a lot of errors. This needs to be implemented though, and it doesn't seem to be an option yet in Chrome according to https://developer.chrome.com/extensions/webRequest.

I think this is high priority, or at least, something I don't want to get lost. How should we track progress on implementing this? Should we make a new issue?

Ping @Bisaloo @brainwane @gloomy-ghost @Hainish @J0WI @wonderchook .

[gloomy-ghost]

it doesn't seem to be an option yet in Chrome

IIRC Chrome managed to fix the issue without forcing extensions to use a new option, so it is only broken with Firefox.

[jeremyn]

@gloomy-ghost That seems to be true, for example, from issue #14117, http://shop.decatorevista.ro/ has working styling and no CORS console messages in Chrome, but has broken styling with CORS console messages in Firefox. I don't know what Chrome does or doesn't specifically allow, though.