Re: [CSP] Clarifications regarding the HTTP LINK Header

On Wed, Nov 12, 2014 at 2:54 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
>> I agree. And, in particular, it would be good to call out what is to
>> happen when <meta http-equiv=Content-Security-Policy> is used with
>> Link rel=preload and how it affects any/all other prefetching,
>> especially preloading done as part of the prescanner.
>
> "Authors are strongly encouraged to place the meta element as early in the
> document as possible to reduce the risk of content injection before a
> protective policy can be read and enforced." [1]
>
> What we're discussing here is an extension of the same problem:
>
> - Link header can initiate a download before any response body bytes are
> received and before <meta> policy is processed and applied.
> -- To guard for this, you should specify your CSP policy in the HTTP header:
> guarantees that the policy is applied against and before *all* requests.
> -- HTTP headers can be re-ordered in transit, we can require that Link
> fetches are delayed until headers are processed (except for Trailers).

I think what you're suggesting seems reasonable. The main thing to
note is that CSP 1.0 and the current CSP 2 draft don't address this at
all, and it's also unclear whether people agree that HTTP LINK is in
scope for CSP, because some parts of the CSP design assume that HTTP
headers are safe, and if HTTP headers are safe then why defend against
safe things? On the other hand, it seems wrong to treat HTTP LINK
differently than HTML <link> given that they are supposed to be
equivalent to each other.

It seems to me like it will be common for some implementers of the
resource hints draft to extract links from HTML and then serve them as
resource hint HTTP LINK headers. It is important to recognize that
doing so would have unexpected consequences when the page contains CSP
<meta>.

Cheers,
Brian

Received on Wednesday, 12 November 2014 23:31:58 UTC