We Keep Coding

Localhost HTTP accessed from HTTPS webpage. Why no "Mixed Content" error? [duplicate]

This question already has an answer here:
Mixed-content request from HTTPS page to HTTP (non-HTTPS) localhost address not blocked
(1 answer)
Closed 1 year ago.
I make a HTTP request:
from a HTTPS JSFiddle: fetch('http://localhost:8090').then(...)
to HTTP localhost or 127.0.0.1
And it works.
No "Mixed Content" errors in Chrome (v89.0.4389.90) and Firefox (v86.0.1). Only Safari blocks the request. However, requests to 192.168.1.x trigger "Mixed Content" errors.
Is localhost explicitly whitelisted in Chrome and Firefox? Or is it scheduled by browser vendors to be blocked with "Mixed Content" at some point, too?
Can this be relied upon, for example, to control a local app bound to localhost that serves HTTP API?

From MDN
Browsers may allow locally-delivered mixed resources to be loaded. This includes file: URLs and content accessed from loopback addresses (e.g. http://127.0.0.1/).
Firefox 55 and later allow loading of mixed content on the loopback address http://127.0.0.1/ (see bug 903966),
Firefox 84 and later allow loading of mixed content on http://localhost/ and http://*.localhost/ URLs, as these are now mapped to loopback addresses (see bug 1220810).
Chrome also allows mixed content on http://127.0.0.1/ and http://localhost/.
Safari does not allow any mixed content.
Both 127.0.0.1 and localhost are considered to be Potentially Trustworthy hence the browser can decide on the result.
https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-origin
The behavior of Safari looks like a bug and it could change in the future. See a discussion here Don't treat loopback addresses as mixed content

How to get full referer URL in Chrome when sec-fetch-site is cross-site

I have a client website that is managed by client team and post clicking on login it comes to the site which is managed by us. Till now, we were extracting the referer URL from the request header and using it to take further actions, but currently due to some changes in the Chrome browser and Edge browser policy we are unable to get the complete referer URL. It works fine in Firefox and Internet Explorer. This is probably because of the browser policy which is restricting the complete referer URL to be send when sec-fetch-site is cross-site. Please help me with some easy code level ways (Java/JSP/Javascript) to extract the complete URL. I tried exploring few links but none helped me resolving this.

Mozilla Firefox and Internet Explorer use a referrer policy called ‘no-referrer-when-downgrade’. Earlier Chrome also used the same policy but it has now shifted to ‘strict-origin-when-cross-origin’ which restricts the referrer URL to only include the domain of the URL.
The resolution to make it work it for Chrome browser as well is to set the policy to ‘no-referrer-when-downgrade’ in the page where your request begins from i.e. the initial page (which in your case is the client managed one), which will help send the complete details and the browser’s default policy won’t be applied. You may refer to below link for better understanding of these changed policies:
https://www.w3.org/TR/referrer-policy/

Why is Application Insights blocked on Firefox as CORS?

I am using the Application Insights JavaScript SDK on my website and Firefox is blocking the requests back to Azure. It is however working on Chrome.
The website is running on https and Application Insights works correctly on Chrome.
On the Console in Firefox I see the following warning:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://dc.services.visualstudio.com/v2/track. (Reason: CORS request did not succeed).
Why is Firefox identifying the request as a blocked CORS request, but Chrome doesn't?
I would like the Application Insights request to succeed from Firefox as well.

Did you installed an ad blocker extension (i.e. uBlock origin)?
If yes, try to disable it.

Couple of points to look at:
Which version are you using for AI. Try upgrading your package to latest one:
You can go ahead try adding the site to exception and see if it works, it could be because of the firefox exception too:
Firefox 'Cross-Origin Request Blocked' despite headers
Last and most importantly check the headers as mentioned by #Bergi in the comment to see if headers are same for both browser.
Additional reference: https://github.com/Microsoft/ApplicationInsights-node.js/issues/133
http://testingfreak.com/how-to-fix-cross-origin-request-security-cors-error-in-firefox-chrome-and-ie/
Hope it helps.

Problems with my Firefox addon and cross domain https

I have an addon for Firefox which modifies a page at http://target.com with data from http://data.com. It does this by making an XMLHttpRequest() in the addon javascript and modifying the webpage accordingly. Neither the target nor the source servers are under my control.
This all worked fine until the target.com website changed to using https. As I was loading data from an http: address I got the following error:
Blocked loading mixed active content
Fortunately data.com also supports https, so I changed the data lookup address to https://data.com, and then I got
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://data.com
I read here that I could add the following to my package.json
"permissions": {
"cross-domain-content": ["https://data.com"]
}
And now I don't get any errors, but the Developer Tools Network page doesn't show any connections being made.
Have I hit a dead end? I understand that CORS requires server support but I assumed that as it worked prior to the target server moving to https it would still work now.
Cheers
Rich

That is one of the issues with using libraries (and not Firefox API)
Try using the native Firefox API eg: Connecting to Remote Content
Native Firefox API runs in the browser scope so there is no CORS to consider.

Chrome blocking iframe requests as cross-origin request even when origins are the same

This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.

I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.

Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.