Re: [CSP] Clarifications regarding the HTTP LINK Header

On Thu, Nov 13, 2014 at 7:05 PM, Brian Smith <brian@briansmith.org> wrote:

> On Thu, Nov 13, 2014 at 8:56 AM, Ilya Grigorik <ilya@igvita.com> wrote:
> > On Wed, Nov 12, 2014 at 4:24 PM, Brian Smith <brian@briansmith.org>
> wrote:
> >>
> >> 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."
> >
> > I don't think we should claim that they are equivalent.
>
> The syntax ("http-equiv") literally says they are equivalent!
>
> > For best results you need to define your CSP policy as early as possible.
> > Specifying it an HTTP header is the best route, as it guarantees that the
> > policy can be parsed and applied before any response body bytes are
> > processed. The second best option, if you can't use the HTTP header
> route,
> > is to provide an equivalent policy via <meta>, which should be placed as
> > early as possible in the document.
>
> Developer tools should warn whenever anything other than "<!DOCTYPE
> html>", "<html>", "<head>", or "<meta charset=...>" appear before
> "<meta http-equiv=Content-Security-Policy>", regardless of whether it
> applies to Link headers.
>

Sounds reasonable. Not sure what the behaviors are today, but if that's not
the case, then worth opening some bugs for it.


> > I don't think we want to get into the business of "must be in first X
> bytes"
> > -- this, by itself, is a usability problem. Similarly, requiring that we
> > wait for <meta> would, once again, force proxies to start flushing fake
> head
> > sections and doing other funny business.
>
> I mostly agree with you. But, don't you already need to wait for <meta
> name=Referrer> so that you know which Referer header to send in your
> HTTP requests for prefetches that result from HTTP LINK? That is,
> doesn't <meta> Referrer have the same problem?
>

Yep, I guess it would.


> > We should just make it clear that if you're using Link to initiate
> fetches,
> > and you use CSP, then your CSP policy should be provided as an HTTP
> > header... which is a security best practice anyway.
>
> The way to make this clear would be to add a note to the HTML
> specification, the CSP specification, and the resource hints
> specification, and then also have developer tools warn when HTTP LINK
> and CSP <meta> are used together.
>

+Referrer Policy.. and, sounds like a plan! Having some shared boiler plate
would make things easier. Perhaps something like...

-----
To guarantee that the specified policy is applied before any resource
requests, the site SHOULD specify the policy via an appropriate HTTP
response header. The user agent MUST process all response headers, and
apply all relevant policies, prior to initiating any resource requests -
e.g. fetches initiated by Link, or other mechanisms. If the policy cannot
be specified as a response header, the developer SHOULD specify it via a
<meta> tag and place it as early as possible in the response body. The user
agent MUST apply the specified policy for all fetches that follow the
<meta> policy declaration.

Note that <meta> policy is applied after HTTP response headers are
processed, so it may not apply to fetches initiated via HTTP response
headers - e.g. Link, or other mechanisms. If the site is using such
mechanisms, it SHOULD specify its policies via HTTP response header.
----

Or some such... I think it covers all the cases?

ig

On Fri, Nov 14, 2014 at 1:22 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Nov 14, 2014 at 4:05 AM, Brian Smith <brian@briansmith.org> wrote:
> > The syntax ("http-equiv") literally says they are equivalent!
>
> Yes, but the feature is defined in a very different way. The name is
> legacy, as so many names throughout the platform. E.g. <meta
> http-equiv=access-control-allow-origin content=*> must not work.
>
>
> --
> https://annevankesteren.nl/
>

Received on Friday, 14 November 2014 19:38:09 UTC