User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce: A GET was called from a https domain to localhost on http. After that a POST call was sent on same way. Actual results: The POST call was aborted. Expected results: Mixed content calls should be enabled to localhost. The W3C is recommend to allow this behavior. https://w3c.github.io/webappsec-mixed-content/#terms
Hi hirschbeckdaniel, Thanks for reporting this issue. Can you provide a specific example/test case for the https GET/POST to see if this issue can be reproduced? Thanks.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
As I understand, you expect requests made to http://localhost being treated as secure, right? That is not a valid assumption, IMO. I can't find any reference to treat localhost insecure requests as secure regarding mixed content blocking in the spec reference from comment 0. I *think* the mixed content blocker issues belong to the security component.
Component: Networking: HTTP → Security
(In reply to vincent.privat from comment #4) > (In reply to Honza Bambas (:mayhemer) from comment #2) > > As I understand, you expect requests made to http://localhost being treated > > as secure, right? That is not a valid assumption, IMO. > > Yes it is, since Firefox 55 which fixes > https://bugzilla.mozilla.org/show_bug.cgi?id=903966 > > I see users are reporting similar problems there with Firefox 60+ Good point. I was not aware of that bug to be honest as it went totally around the necko code. I'm moving this bug to the same component and adding some folks.
Component: Security → DOM: Security
See Also: → 903966
hirschbeckdaniel - Could you provide the specific error that the browser console displays when the load is blocked. It might actually be a CORS error instead of a mixed content blocker error.
Here the error code from the browser when trying to do an ajax request from a https:// website to http://localhost. "Blocked loading mixed active content "http://localhost:49101/" For my understanding of the w3c specs, this call should be allowed.
(In reply to Simone Granata from comment #8) > Here the error code from the browser when trying to do an ajax request from > a https:// website to http://localhost. > "Blocked loading mixed active content "http://localhost:49101/" > > For my understanding of the w3c specs, this call should be allowed. See: https://bugzilla.mozilla.org/show_bug.cgi?id=903966
Hey Birunthan, any chance you could take a look at this bug? Within Bug 903966 we started to allow mixed content requests to localhost. I just browsed the code and in my opinion IsPotentiallyTrustworthyLoopbackURL() does the right thing on the right spot within nsMixedContentBlocker and therefore should also greenlight that ajax request from comment 8. Not sure where the problem is, could you try to debug and potentially add a test so we don't regress that again? Thanks!  https://searchfox.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#745
I am going to assign this one to myself and take a look. Probably there is so mis-alignment with the secure context spec since the MixedContentBlocker code looks sane to me. Anyway, I'll have a look.
Assignee: nobody → ckerschb
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
(In reply to Honza Bambas (:mayhemer) from comment #2) > I can't find any reference to treat localhost insecure requests as secure > regarding mixed content blocking in the spec reference from comment 0. It's a "MAY" in the secure contexts spec (referenced from the mixed content spec https://w3c.github.io/webappsec-secure-contexts/#localhost
this is likely to be optional. we must disable it for our localhost-based tests and also allow developers (platform and firefox) to disable it when local testing work regarding content blocking is under way. thanks.
Summary: Mixed content call to localhost → Stop treating "http://localhost/" (by name) as mixed content
The isSecureContext checks already treat "localhost" the right way, so this bug is essentially about aligning the mixed-content blocker with that, which is bug 1295777. Possibly want to dupe this to that, but for now I'll make it "depends on" for clarity.
Depends on: 1295777
Assignee: ckerschb → nobody
Status: ASSIGNED → NEW
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.