letitz
commented
2 years ago You're right, this is a currently a sharp edge. It should be at the very least mentioned in the specification.
I'm not sure there's much we can do to improve the state of affairs, since this looks very much like DNS rebinding from the point of view of the browser. DNS rebinding is typically used to perform attacks that this specification aims to mitigate.
See also #62 which deals with a similar issue that proxy users can run into. In that case, the browser knows about the use of a forward proxy, so it can apply preferential treatment to affected requests.
There exists conditions that, when met with this specification, result in unintended side-effects and breakage. When a client consumes a resource(s), that while on an internal network resolves to be private, and then subsequently switches to a public network, wherein resolution turns to public, preflights are triggered. These conditions can be replicated, for resources that resolve to private addresses while on an internal network and public addresses while on a public network, by leaving the private network and attempting to use the resources again on a public network.
In these cases, the browser sees resources that were private at last request, yet being requested by public IP space. Current default browser settings do allow the real, originating request to proceed, and everything gets back to working as normal. However, turning the Chromium flag "Respect the result of Private Network Access preflights" to enabled, in order to test what would be this specifications complete results, prevents the originating requests going through, which leads to breakage.
I also suspect, but did not replicate, that DNS caching by either (or both) the operating system and browser could result in unintended preflights.