Bad score should not be assigned to sites claiming http://127.0.0.1 in their Content-Security-Policy header

[Idopte]

Currently, there is a -20 score assigned to sites advertising http://127.0.0.1 in their Content-Security-Policy header (due to "site allows resources to be loaded over HTTP" rule). We think this is not appropriate for the specific case of 127.0.0.1. The pitch is as follows:

HTTPS is not designed to secure exchanges between two processes on the same machine. Its purpose is to secure exchanges between a remote client and a remote server, with communications that pass through untrusted routers.

Between local processes running on the client machine, there is no remote communication. The threat that could happen is the presence of malware on this same machine. In this case, it is clear that the machine is compromised and that HTTPS would not solve anything.

HTTPS is therefore of no use between a local service and the browser.

In fact, it is even detrimental to choose HTTPS rather than HTTP. Indeed, HTTPS will require the installation of a "fake" trusted root certificate in the system's trusted authorities (1).

Moreover, it is stated in the W3C specifications (2) that, a web application in HTTPS (which is normally not allowed to access resources in HTTP because of the Mixed-Content rule) can make HTTP requests on 127.0.0.1. There is an explicit exception to the Mixed-Content rule on 127.0.0.1. This was put in place precisely to avoid compromising the security of the machine by installing these "fake" authorities for applications that require local services. It has been officially deemed acceptable to use HTTP for local communications.

Therefore, we consider that observatory.mozilla.org is making a mistake by considering that a bad score should be assigned to an application that declares http://127.0.0.1 as a possible destination in the Content-Security-Policy header. Access to an HTTP resource is indeed bad, except for 127.0.0.1.

1 Certification authorities are forbidden to issue certificates for 127.0.0.1, because it is not a specific machine and its identity cannot be proven. The only solution is therefore to produce its own root, or a self-signed certificate for 127.0.0.1 and install it in the system, so that the browsers accept the HTTPS connection. But this also gives the software that does this "too much" power (and puts some constraints for installation on most platforms, such as being admin of the computer).

2 see https://w3c.github.io/webappsec-mixed-content/#should-block-fetch and
https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy