Open annevk opened 6 years ago
Talked with @yoavweiss about this today. I think what we agreed on was something like the following:
Add something to CSP that answers the question "Would a request to |url| be allowed by fetch directives?". That algorithm would walk through all the fetch directives specified in the each active policies, and return true if a request to |url| would be allowed by any of them. e.g. default-src https://site.example; img-src https://images.cdn
would return true
for https://site.example
and https://images.cdn
.
Hook into this algorithm from Fetch's Obtain a connection (which I'm going to charitably assume is part of the preconnect
flow).
Figure out some way of establishing this algorithm's control over dns-prefetch
.
Call it a day.
WDYT?
/cc @andypaicu, @dveditz, @ckerschb
Sounds good to me. (The only thing that's still unclear to me is how WebRTC's algorithms tie into all this, but I guess we'll track that as part of #92.)
Sounds good to me. (The only thing that's still unclear to me is how WebRTC's algorithms tie into all this, but I guess we'll track that as part of #92.)
Short answer: connect-src
seems reasonable. Long answer: I'll go look at that bug.
Hi folks, I just wanted to ask if there are any plans to progress this?
This is super important for our use case - being able to stop data exfiltration from a sandbox that is used to render private data.
/cc @noamr - as it's related to the resource hints processing model work
I don't think connect-src
is right here. You could have an images CDN that you want to download images from, and obtain an early connection to that domain for performance. image-src
should suffice in that case.
I suggest that if there is any directive that allows fetching from a particular origin, then dns-prefetch
and preconnect
should be allowed. So if an origin is allowed to be accessed for images or scripts or what not, it should also be allowed to be accessed via preconnecting or DNS prefetching to speed things up.
btw I think this should also be the case for prefetch
but I'm not keen on reopening that.
I added some thoughts in https://github.com/w3c/webappsec-csp/issues/542.
I think that if we don't want to relax restrictions like I'm proposing, we should go with prefetch-src
for dns-prefetch
and preconnect
rather than connect-src
.
@noamr: connect-src
was only my suggestion for WebRTC. I think we're on the same page with dns-prefetch
and preconnect
, both of which I'd suggested should look at all the fetch directives (see https://github.com/w3c/webappsec-csp/issues/282#issuecomment-357194535 above). That hasn't been a high-enough priority for anyone to actually implement, but I still think it's a reasonable approach to the problem.
@noamr:
connect-src
was only my suggestion for WebRTC. I think we're on the same page withdns-prefetch
andpreconnect
, both of which I'd suggested should look at all the fetch directives (see #282 (comment) above). That hasn't been a high-enough priority for anyone to actually implement, but I still think it's a reasonable approach to the problem.
Oh, I guess I missed that and ended up suggesting the same thing.
btw I think the same algorithm should apply to prefetch
and not just to preconnect
, as prefetching has no observable effect on the document.
Raising this separately from #107 as that is mostly focused on the other types (which go through Fetch).
See @samuelhorwitz's comment at https://github.com/whatwg/fetch/issues/658#issuecomment-356093141.
If we do this it might make CSP a natural place to also define the
X-DNS-Prefetch-Control
header (see https://github.com/w3c/resource-hints/issues/75); again, in cooperation with HTML most likely.