Govern dns-prefetch and preconnect with CSP

[annevk]

At the very least the default policy ought to be enforced.

cc @noamr

[annevk]

I guess ideally this is done by Fetch, but we don't want to enforce it for all callers of "resolve an origin". Perhaps we can make it such that internal callers in Fetch end up bypassing it. (If we do that I should move this issue to the Fetch repository.)

[noamr]

My thinking about it is to use have a "fake" request with prefetch initiator and perform a CSP check on that (with the newly defined CSP rules for prefetch).

We can wrap connect+resolve in Fetch with a call that accepts a client instead of partition key that makes this call.

btw a very different alternative I thought about is to have a "preconnect" or "dns-prefetch" destination, and exit early inside fetch based on that destination. WDYT @annevk ?

[annevk]

I think overloading "fetch" is probably undesirable. E.g., by the time it calls obtain a connection it will have already spun up service workers and such. And other specifications that should invoke "obtain a connection" (e.g., WebRTC and WebTransport) should also be subject to CSP. They should also be subject to some other things, such as port blocking: https://github.com/whatwg/fetch/issues?q=is%3Aopen+is%3Aissue+label%3A%22topic%3A+connections%22.

However, you do make me wonder if "dns-prefetch" is doing the wrong thing currently. If a proxy is configured that doesn't return "DIRECT", should we even be invoking resolve an origin? That's probably bogus.

cc @ricea

[noamr]

Good point regarding proxies, I'll fix that together with figuring out the CSP bit.

[noamr]

Define preconnect and dns-prefetch with CSP whatwg/fetch#1620

whatwg/fetch#1620