-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Govern dns-prefetch and preconnect with CSP #9035
Comments
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.) |
My thinking about it is to use have a "fake" request with 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 ? |
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 " cc @ricea |
Good point regarding proxies, I'll fix that together with figuring out the CSP bit. |
|
At the very least the default policy ought to be enforced.
cc @noamr
The text was updated successfully, but these errors were encountered: