Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content
Fixed Issue #11963735
Details
- Author
- Birunthan M.
- Created
- May 10, 2017
- Privacy
- This issue is public.
- Found in
- Standard affected
- Secure Contexts
- Fixed in build #
- 16.16246
- Reports
- Reported by 16 people
Sign in to watch or report this issue.
Steps to reproduce
According to the spec, content from loopback addresses should no longer be treated as mixed content even in secure origins. See: - https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 - https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy In other words, e.g. fetch('http://127.0.0.1:1234/foo/bar')
on a HTTPS site should be allowed without triggering the mixed content blocker. Note Chrome (and soon Firefox) only whitelist ‘127.0.0.1’ and '::1’. See: - https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e - https://bugzilla.mozilla.org/show_bug.cgi?id=903966
Attachments
0 attachments
Comments and activity
-
Birunthan M. May 10, 2017 2017-05-10T17:09:06.38Z
Changed Steps to Reproduce
-
Microsoft Edge Team
Steven K. May 11, 2017 2017-05-11T16:42:22.48Z
Changed Assigned To to “Steven K.”
OSG V. Jun 13, 2017 2017-06-13T03:13:38.607Z
Changed Assigned To to “Venkat K.”
Venkat K. Jun 13, 2017 2017-06-13T22:19:56.27Z
Changed Assigned To from “Venkat K.” to “Ali A.”
Ali A. Jun 26, 2017 2017-06-26T17:35:09.01Z
Changed Assigned To from “Ali A.” to “Rajat J.”
Ali A. Jun 26, 2017 2017-06-26T17:35:09.01Z
Changed Status to “Confirmed”
Rajat J. Jun 27, 2017 2017-06-27T20:57:10.627Z
Changed Status from “Confirmed” to “In progress”
Rajat J. Jun 30, 2017 2017-06-30T02:43:50.13Z
Changed Status from “In progress” to “Fixed”
-
Chris V. Aug 22, 2017 2017-08-22T14:26:52.693Z
Has there been discussion of backporting this fix in a security update for IE11? In order to migrate to this model, we would need it to be supported across all major browsers, and IE11 looks like it’s becoming the sticking point.
-
Derek Z. Dec 2, 2017 2017-12-02T00:25:19.283Z
Does “FIXED, NOT YET FLIGHTED” mean this issue will be fixed in a future release of Edge? Is there a particular version that will contains the fix?
-
Anonymous Apr 2, 2018 2018-04-02T03:36:07.18Z
#16110645 was closed as a duplicate of this bug with an indication that the bug was solved in Edge 16245. However, this bug report is still listed as "Fixed, Not Yet Flighted". Please advise what that means…has the intended fix been released or not?
-
Jason M. Apr 23, 2018 2018-04-23T19:51:23.873Z Microsoft Edge Team
Apologies for the lack of update to this issue. There’s a bug in the logic and fields we search on to automatically update the public bug status in some combinations.
This bug is closed and released. We shipped it with the Windows 10 Fall Creators update (1709). Again apologies this bug wasn’t automatically update to report the correct status.
-
Anonymous Apr 23, 2018 2018-04-23T20:02:24.72Z
Jason M. - Appreciate the follow-up. However, I would urge the Edge Team to review the issue again. My understanding is that the Windows 10 Fall Creators update (1709) introduced this bug rather than resolving it.
-
Chris V. Apr 23, 2018 2018-04-23T21:01:11.82Z
I agree. I have tested this issue with the latest version of Edge, but am still seeing the SEC7111: HTTPS security is compromised error. Jason M., you may want to review this ticket.
-
Vincent P. May 1, 2018 2018-05-01T17:05:42.907Z
This issue is not fixed in 1803. We get the same warning (SEC7111) when calling http://127.0.0.1:8111/load_and_zoom? from https://www.openstreetmap.org
-
Microsoft Edge Team
Angelo L. May 1, 2018 2018-05-01T17:39:53.067Z
Changed Steps to Reproduce
Jason M. May 3, 2018 2018-05-03T17:26:08.253Z
Changed Assigned To to “Rajat J.”
Jason M. May 3, 2018 2018-05-03T17:26:08.253Z
Changed Status from “Fixed”
-
Jason M. May 3, 2018 2018-05-03T17:26:08.253Z Microsoft Edge Team
Thanks all for the feedback on this. We reviewed again, this time using jQuery for an XHR request and we can see that over the new Fetch networking stack with XHRs, this is indeed still an open issue. Coding is happening now for the next release and we will review for back level servicing also.
Thanks again. -
Microsoft Edge Team
Rajat J. May 23, 2018 2018-05-23T04:44:38.533Z
Changed Assigned To from “Rajat J.” to “Angelo L.”
Rajat J. May 23, 2018 2018-05-23T04:44:38.533Z
Changed Status to “Fixed”
-
Curtis C. May 30, 2018 2018-05-30T19:16:05.147Z
Is there an estimated release date for this fix? I’m nearing release of an application that is currently jumping through hoops to work around this issue and would like to be able to remove my work around.
-
Jason M. Jun 26, 2018 2018-06-26T19:37:15.78Z Microsoft Edge Team
This fix is now flighting in the most recent Windows Insider Preview builds (17692+). Please test your applications against this build and provide us feedback so that we can collect data about the fix for servicing consideration.
Many thanks for your feedback so far.
-
Curtis C. Jun 27, 2018 2018-06-27T21:46:02.537Z
I updated to the Insider Preview (Windows 10 Enterprise) and it is working great. Thanks!
Edge details:
Microsoft Edge 43.17704.1000.0 -
Jason M. Jul 6, 2018 2018-07-06T17:57:59.983Z Microsoft Edge Team
Based on flighting information, this fix has been approved for both our April 2018 and October 2017 releases of Windows 10.
Failing any issues we are yet to find, users on the April update who check for updates manually will get this fix the first week of August. Users on the October 2017 update who manually check will be sent the fix in the last week of August.
This will also be included in a mandatory security update in September for users on both releases.
Thanks again for your help in bringing this to our attention and your testing feedback.
Jason
-
Nattachai W. Sep 27, 2018 2018-09-27T02:57:51.92Z
Asking this again in 2018, is there any possibility to port back for IE11?
-
Dale H. Nov 5, 2018 2018-11-05T18:38:22.92Z
Has this fix been officially implemented as of the Fall Creators Update (1709) or the April 2018 Update (1803)?
I can see in Jason’s message that it was expected to be fixed, but would appreciate clarification on whether it actually happened or not.
This particular bug prevents secure Progressive Web Apps (aka UWP Hosted Web Apps) from communicating with localhost resources, because they use Edge under the hood. As you can imagine, this could be a significant limitation in enterprise environments, where OS updates don’t happen nearly as quickly/frequently as they do for individual users.
(P.S. I can’t wait until Edge updates are decoupled from Windows udpates. I believe this is a major factor in why this browser isn’t widely adopted like Chrome/Firefox.)
-
Diego C. Jan 25, 2019 2019-01-25T14:21:56.8Z
Microsoft:
was or not delivery this fix in October 2018?
thanks,
Diego
You need to sign in to your Microsoft account to add a comment.
Sign in