Re: [CSP] Clarifications regarding the HTTP LINK Header

On Wed, Nov 12, 2014 at 3:31 PM, Brian Smith <brian@briansmith.org> wrote:

> 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.
>

Agreed, I think CSP spec should have some language to cover Link.

We already provide a mechanism to set the policy via HTTP headers, we just
need to clarify that any fetches initiated on behalf of HTTP headers (i.e.
Link) are subject to CSP, and that by definition to cover this case... CSP
policy should be provided as an HTTP header.


> 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>.
>

Yes, the key use case here is proxies: request hits CDN edge server --> CDN
routes request to origin *and* simultaneously flushes response header back
to the client with Link's to critical resources based on observed traffic /
<insert smart strategy here>... Many FEO services already do this today,
except they synthesize fake <head> with XHR fetches, <object> tags, and
other ugly business. Link with rel=preload enables a simple, interoperable,
and CSP-friendly mechanism to improve what's there today.

ig

Received on Wednesday, 12 November 2014 23:44:47 UTC