Closed Bug 1376310 Opened 7 years ago Closed 4 years ago

Allow localhost CORS preflight requests without blocking it as mixed content

Categories

(Core :: DOM: Security, enhancement, P3)

Product:
Core
Component:
DOM: Security
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla75
Tracking Flags:
Tracking Status
firefox75 --- fixed

People

(Reporter: poiru, Assigned: sstreich)

References

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

Bug 1376310 - Ensure a nsIDocShell after checking IsOriginPotentiallyTrustworthy r=ckerschb
47 bytes, text/x-phabricator-request
Details | Review 
See bug 903966 comment 27.
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Still exists in 57.0a1 (2017-09-18) (64 bit)
Still exists in 59.0.1
Biru, are you planning on completing this?  We got a request on a duplicate bug 1440370.  Want to let the reporter know if its on our roadmap in the near future.  Thanks!
Flags: needinfo?(birunthan)
Any update on this?  Microsoft Edge had a similar issue and has just fixed it with their latest build available on Windows Insider.  It would be great to have this work consistently between Edge, Chrome, and Firefox.
Any update on this? This is very bad, because only Firefox blocks this kind of connection. If you try to do an ajax request from https://webapp/index to http://localhost:49100 you receive a mixed content error and if you do an ajax request to http://127.0.0.1:49100 you receive a CORS error, equal if I activate the CORS filter on my native app on 127.0.0.1:49100. Can you please fix this asap?
It seems, that Firefox doesn't send any preflight request to the target server, when trying to make an ajax or fetch request from a https://website to http://127.0.0.1:<any free port>/api/<service>. @Developers: Is this a bug or is this really intended? Because Chrome and IE Edge allows that. I think is a bug. Can you please give a feedback to this?
Same problem here. I want to access http://127.0.0.1 from a https://webapp and get the CORS error "CORS request did not succeed", so it seems that the preflight request is not sent at all. Edge and Chrome however work fine.
So please fix this as soon as possible.
I am using FF 63.0.1 (64-Bit)
Confirmed - same problem here. Please resolve the issue so that CORS preflight requests can also be used in FireFox ...
Still seeing this issue. I am going to have to drop support for our Firefox users until this is fixed.
We have a lot of users finally leaving IE.  Without having this fixed, we will likely have to recommend that our customers put all users on Chrome or whatever Microsoft comes up with now that Edge is done.
just discovered that opening an EventSource from a secure context to:
1) http://localhost:8080 -> fails
2) http://127.0.0.1:8080 -> fails
3) http://[::1]:8080 -> works!

So using the IPv6 localhost "[::1]" could be a workaround for this issue.

I have the same problem. I have to use chrome which I don't really want to use for developing, so problem has to be solved.

See Also: → 1535547

We are heavily using communication between https client and a service on http://127.0.0.1.
Only in Firefox, we can send GET and POST requests, but PUT requests get blocked.
Cors headers are correctly set on the server, allowing the PUT method. PUT requests work in Chrome.

Is there anyone from Mozilla-Team seeing this bug? This is now open for more than 2 years and not a single reaction.

@s.mellal, @daniel:
did you try to change use IPv6 http://[::1] instead of http://127.0.0.1 ?

@Benjamin Klaus
I'm having the same issue. Tried using IPv6 instead of IPv4 but it did not help (Firefox version 66.0.3).
My advice is to avoid triggering CORS preflight by using "simple requests" if possible until this issue has been resolved: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests

yeah, using "simple requests" is possible, if you are also developing the endpoint on localhost you're communicating with. However thats not always the case and it's also not amusing if I have to change the request methods of the REST API of an other application just to get it work with Firefox...

We tried exactly what I wrote in the last comment in our application: We changed all PUT requests to POST and all Content-Type headers to "text/plain" in order to be categorized as "simple request" by Firefox where no CORS preflight request is sent. Result: basically it worked, but we also need to use EventSource() for server sent events -> this again resulted in the well-known CORS error. Unfortunately there is no possibility to change the characteristics of the browser-generated requests by constructing an EventSource and therefore this again breaks our app in Firefox...

Conclusion: Please, Firefox-Team fix this issue or at least comment on it, otherwise we have to drop Firefox-Support!

I can confirm the problems mentioned by @Benjamin Klaus. It would be awesome to have at least some kind of reaction of Team Firefox. Even if it is possible to work around this issue, by using the mentioned "simple requests", adapting the requests of the EventSource API for this scenario isn't possible after all.

Honestly, we don't want to drop the support for Firefox, because we really appreciate the work of you guys. However, we cannot make any clear decision until we have a reaction from you - other than to drop the support.

So.. Pretty Please with Sugar on Top. :) Please provide some thoughts and comments on this issue.

(In reply to Alija Sabic from comment #21)

So.. Pretty Please with Sugar on Top. :) Please provide some thoughts and comments on this issue.

I am clearing the flags so this bug shows up in our weekly triage (which happens every Tuesday) in which we will re-evaluate the importance of this bug.

Priority: P3 → --
Whiteboard: [domsecurity-backlog1]

Thanks, great to hear that!

Just a comment for the re-evaluation:
As stated in the last note of https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content there is that decision that mixed content is allowed for 127.0.0.1. The current implementation of Firefox is inconsistent since normal requests to http://127.0.0.1 are allowed from a secure context, but preflight requests are not allowed. Therefore to my mind either both normal and preflight requests should be allowed (which I hope) or both denied.

Just noticed the same issue with an secure-only context (https). Our webapp from host https://grid.asterics.eu issues requests to https://couchdb.asterics-foundation.org - so its communication to another https page from an secure context. However I get the same issue:

Reason: CORS request did not succeed <<

Steps to reproduce:

  1. Go to https://grid.asterics.eu/latest/app/#register
  2. type any username in the first field
  3. open console -> there is the CORS error because of an request made by the app to check if the username is valid

tested with latest Firefox (66.0.3, 64-Bit) on Win10 and Win7.

The changes within Bug 1402530 will stop blocking 'localhost' as mixed content. Adding dependency to Bug 1402530 which should fix the problem here.

Depends on: 1402530
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

Basti, after we have fixed Bug 1402530, could you verify that this bug has resolved as well? If so, we can mark this one as fixed as well. Thanks!

Flags: needinfo?(birunthan) → needinfo?(streich.mobile)

So I didn't verify how Chrome behaves but it seems the source at least suggests it works the way I have been preventing you implementing basti, sorry about that.

So it seems it is safe to start allowing this everywhere in Bug 1402530.

(In reply to Benjamin Klaus from comment #24)
I do not believe this issue is related to CORS. Firefox does not trust the certificate provided by https://couchdb.asterics-foundation.org:3001/ (you should get an error if you open the URL in FF).

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)
Thanks for re-evaluating this bug! Hoping that Bug 1402530 will resolve this as well

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)

Basti, after we have fixed Bug 1402530, could you verify that this bug has resolved as well? If so, we can mark this one as fixed as well. Thanks!

Hey! I just checked that case and can confirm that this will is fixed with the Patch for Bug 1402530

Flags: needinfo?(streich.mobile)

Great to hear that! We really appreciate it that someone takes care of resolving this issue, thank you very much!

So is this fixed now? At least for the IP address case?

I think it should be fixed now, but I guess it will be only available with newer versions of FireFox. Let's hear what the developers will say...

Bug 1402530 was fixed for Firefox 68, which is the current Firefox release version as of a few days ago. So either this is fixed in Firefox release, or bug 1402530 did not fix it.

Okay. I just checked the version of firefox I'm using. I'm still on 67. But I'll try to upgrade it tomorrow, run some test, and then post the results. Anyway, where can I look up the version of firefox for which bugs are fixed?

Anyway, where can I look up the version of firefox for which bugs are fixed?

It can be a little complicated. Bug 1402530 is a simple case: if you load it and look in the "Tracking" section it says: "Target: mozilla68". That means the fix was checked in while 68 was in development, and generally means that 68 should have the fix.

There can be complications when fixes are backported to beta or release branches or when fixes are backed out on beta or release branches. Generally that information will be in the "Firefox Tracking flags" section, where bug 1402530 has "fixed" for "firefox68". An example of how this can work is bug 1409773 which has "Target: mozilla70" and "fixed" for both "firefox70" and "firefox69" in the tracking flags, because it was fixed for 70 and then backported to beta 69.

Maybe we always set the tracking flags now; if so, things are simpler than last I looked and you can just ignore the "Target" bit altogether. ;)

just tested this with Firefox 68.0.1 (64-Bit), but unfortunately it still looks the same:

from a secure context I tried HTTP PUT requests to the following addresses:

  1. http://127.0.0.1:8081
  2. http://localhost:8081
  3. http://[::1]:8081

all still failing with the error: "CORS request did not succeed".

I'm having the same problem with Firefox 72.0.2 (64-bit) and Firefox Nightly 74.0a1 (2020-01-22) (64-bit)

  • https website with a POST request to http://localhost:5000 or http://127.0.0.1:5000
  • if the authentication header is set, i get a "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:5000/status. (Reason: CORS request did not succeed)" error
  • if there's no authentication header, everything is ok

The same code runs on the latest versions of Chrome, Opera and Edge (chromium)

Assignee: nobody → sstreich
Status: NEW → ASSIGNED
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b0c31dc335db
Ensure a nsIDocShell  after checking IsOriginPotentiallyTrustworthy r=ckerschb

https://hg.mozilla.org/mozilla-central/rev/b0c31dc335db

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox75: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: