Interaction of 103 and CSP

[annevk]

At the point of a 103 there's no CSP policy yet. How does fetch even get invoked for those?

[yoavweiss]

I don't think this is the right repo to open issues against Early Hints. You may want to try https://github.com/httpwg/http-extensions

[annevk]

Sigh, how sure are you that this is not going to be a game of ping-pong?

[yoavweiss]

@mnot @kazuho - do you agree that the above issue belongs at the HTTPWG?

[annevk]

As I expected this is found to be an issue with rel=preload, not Early Hints (see httpwg/http-extensions#687 (comment)).

[kazuho]

FWIW, my view is that CSP does not "restrict" how resources designated by preload links are being fetched, and therefore that clients do not need to worry about what the final value of the CSP header field will be when evaluating the preload links in a 103 response.

Consider the following example.

HTTP/1.1 200 OK
Content-Security-Policy: img-src https://example.com/; script-src 'none'

...
<script src="/script.js"></script>

The client will not fetch /script.js, because it is not allowed by the CSP header field.

Consider the next example.

HTTP/1.1 200 OK
Content-Security-Policy: img-src https://example.com/; script-src 'none'
Link: </script.js>; rel=preload; as=image

...
<script src="/script.js"></script>

/script.js is fetched, even though CSP says do not.

CSP defines what to fetch based on how it is used. Preload links are a way to let the client start fetching resources before it sees how it is actually being used.

To put it another way, it is already the server's responsibility to sanitize the preload links that it sends. Adding support for preloads links in 103 does not change the fact.

[annevk]

Meh, as I said elsewhere, what if the Content-Security-Policy was instead default-src 'self'?

[kazuho]

You can do whatever you want.

I am merely pointing out that checking the value of "as" attribute of a preload link against the value of CSP is not a security feature (because the value of "as" can be faked). And that therefore clients do not need to wait for the final value of CSP to determine how to handle preload links in 103.

[annevk]

@kazuho that's simply not true for the policy I defined.

[kazuho]

@annevk If that is the case, do you think that the client is allowed to fetch /script.js when it sees the header fields of the following response (but before it sees the script tag)?

HTTP/1.1 200 OK
Content-Security-Policy: img-src https://example.com/; script-src 'none'
Link: </script.js>; rel=preload; as=image

...
<script src="/script.js"></script> <!-- this is the only place where /script.js is used -->

PS. My view is that the preload specification allows the client to start fetching /script.js when it sees the link header field, because the designated type (image) is not forbidden by the CSP header field. As I said before, this is an example showing that "preloads" initiated by link header fields are not governed by CSP (which defines what to load based on how it is being used).

[annevk]

Sure, if your CSP policy is weak with respect to outgoing requests, outgoing requests can be made.

[kazuho]

Right. And that is even the case for default-src being none. For example, https://cdn.example.com/script.js will be fetched in the following example.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Security-Policy: img-src https://cdn.example.com/; default-src 'none'
Link: <https://cdn.example.com/script.js>; rel=preload; as=image

...
<script src="https://cdn.example.com/script.js"><!-- this is the only place where /script.js is used -->

So if you want to forbid preload links initiating fetches that might violate CSP, you need to ignore all preload links if the URL of the link is forbidden by any destination type. For example, if object-src is set to none, a client will be required ignore all preload links regardless of their types.

I do not think that we would want make such a change the preload's spec, because that would make it very hard to use preload and CSP at the same time.

Therefore, I suggest to continue considering that the preload links as not being policed by CSP, which in turn removes the concern of preload links found in 103 potentially violating CSP.

[annevk]

It will only be fetched because you left a gaping hole in your policy?