Re: [CSP] Clarifications regarding the HTTP LINK Header

On Wed, Nov 12, 2014 at 3:43 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
> 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's quite a usability failure, though. We're saying "Hey, here's
<meta http-equiv=Content-Security-Policy> to make CSP easier for you
to use, but don't use it, because it's not equivalent to the HTTP
Content-Security-Policy header."

Perhaps, instead, we should require the browser to look for <meta
http-equiv=Content-Security-Policy> during prescanning, and do
prescanning before processing any LINK headers? That's much better
usability. This would make prescanning required, and it would require
an authoring requirement that <meta
http-equiv=Content-Security-Policy> appear in the first 1024 bytes,
but it would solve a lot of unresolved and/or unfortunately-resolved
issues with CSP <meta>. What do you think?

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

Could you please update the resource hints draft to add a requirement
that all <meta http-equiv=Content-Security-Policy> elements be
converted into Content-Security-Policy header fields whenever a link
within the HTML document is converted to a HTTP LINK header?
Otherwise, the resource hints spec isn't really CSP-friendly.

Cheers,
Brian

Received on Thursday, 13 November 2014 00:24:39 UTC