Bug 250776 – Content-Security-Policy upgrade-insecure-requests should not be applied to localhost

• Status: NEW
• Component: DOM

[Jaime Rivas]

Hello, I'm filing this under DOM but not sure if it is the right place. Please updated as needed :)

Safari tries to upgrade to https in localhost. Content-Security-Policy upgrade-insecure-requests should not be applied to localhost. Chrome and Firefox both do NOT upgrade insecure requests to trustworthy localhost.

Specific example: A webapp served over https tries to call a locally installed daemon which exposes an endpoint in localhost. Since Safari tries to upgrade the call to localhost, we cannot communicate with the daemon.

Please see some links for more context:
https://bugzilla.mozilla.org/show_bug.cgi?id=1447784
https://github.com/github/secure_headers/issues/348

Thank you!

[Radar WebKit Bug Importer]

<rdar://problem/104393990>

[Brent Fulgham]

We'll have to think about this in the context of Local Network Access.

Part of this is related to our choice to not treat localhost as definitively trustworthy on secure sites. Once more rigorous protections are in place so users can understand when a site on the internet reaches out to local services it may make sense to relax things here.

I guess the use case here is a site that sends the UIR header, but doesn't want localhost to be upgraded. I understand this is convenient for web app authors, but it doesn't especially make sense from the standpoint of the UIR header's use.

[Matthew Finkel]

Conceptually, this is a reasonable request because no one can receive a valid TLS certificate for localhost from a public CA. But, I agree with Brent that this is not a straight-forward bug. The "Upgrade Insecure Requests" specification does not explicitly give localhost an exception when deciding if the request should be upgraded. Instead, it only upgrades requests that are "a priori insecure" [0]. Chrome and Firefox handle localhost as a priori secure, but at this time WebKit handles it as insecure. There have been discussions around changing this (e.g., Bug 171934, Bug 218980), but they are currently open.

[0] https://www.w3.org/TR/upgrade-insecure-requests/#should-upgrade-for-client

[Karl Dubost]

Jaime,

> A webapp served over https tries to call a locally installed daemon which exposes an endpoint in localhost. Since Safari tries to upgrade the call to localhost, we cannot communicate with the daemon.

Could you be more explicit about current use cases?
Are there apps breaking currently on WebKit because of this difference?
And what are the type of apps, business who would need this feature?

This would help to figure out the scope.

[Jaime Rivas]

Thank you all for your comments and for the links to the other issues.

@Karl: for sure, let me elaborate. 

We have a native application (let's call it "Tools") installed on the users' computers (the employees of several companies). The Tools application interacts with the local computer (it can save files, edit files, etc. It is something like Git version control). 

Tools acts as a daemon and exposes an API in localhost, which can be called from custom webapps from those customers (so all those different webapps from different domains can call the same Tools daemon).

One solution (from the other linked issues) is to enable Private Network Access to allow secure contexts (the webapps over https) to access private networks after a CORS preflight and in that case treat localhost as a secure context and enable http communication. 

For now, we have had to force all Mac users to use Chrome, Edge, or Firefox :(. It is a pity that they cannot use Safari, hopefully this proposal can make it work. 

Thank you very much!

[Karl Dubost]

Thanks a lot. 
Adding Anne.

[Anne van Kesteren]

Until we have a path toward fixing bug 171934, I'm not sure it makes a lot of sense to put effort into this. We could address it now, but it would still result in localhost not being accessible.

[Jaime Rivas]

Hi Anne, Karl, Matthew, Brent - I have been following the other issue (bug 171934) but I haven't seen any updates. Now that Sonoma has webapps that can be added to the dock and web push, it is such a pity that we cannot use Safari because we cannot reach localhost from htpps. Is there any chance that you could push it internally? I'm sure that all our Mac users will be delighted to be able to use Safari again with our webapps. Thank you very much in advance!