W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Header Policy Vs. Meta tag policy

From: Mike West <mkwst@google.com>
Date: Tue, 10 Jun 2014 06:50:32 +0200
Message-ID: <CAKXHy=d1RgYhFxC1oojj7joZb+nT_4Vf4T4BUQj2VdFPv8EoBA@mail.gmail.com>
To: Kevin Hill <khill@microsoft.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Jun 6, 2014 at 3:39 PM, Kevin Hill <khill@microsoft.com> wrote:

> Looking at section 3.1.3 HTML meta Element of the 1.1 spec.
> Content security policy (http-equiv="content-security-policy")
> 1. If the user agent is already enforcing a policy for the document, abort
> these steps.
> Is the intent that if a server policy is supplied that any meta elements
> would be ignored?


When I took a first read I skimmed over this part and had thought that meta
> Element tags would be added to the policies coming from the server. This
> seems to be how this 1.1 option is implemented in Chrome currently.

That is how things are implemented in Chrome at the moment. Chrome's
implementation of <meta> predates the spec, and I'll bring it into line
with whatever the group ends up publishing.

> Or is this trying to capture the potential race condition depending on
> where a developer places the meta Element in their page?

The concerns aren't regarding race conditions, but potential attack
surface. Folks are concerned about attackers being able to modify the CSP a
page expects.

I'd prefer to maintain the ability to tighten a page's policy, as I think
there are totally valid use cases for such a thing, but so far I've been
the only one in favor of that, and the spec reflects my understanding of
the group's consensus.

Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 10 June 2014 04:51:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC