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

Re: CSP: Problems with referrer and reflected-xss

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 4 Nov 2014 15:03:39 -0800
Message-ID: <CAEeYn8haq4jDYnog=EU5dpBGZ2j0OmFd-uCPLbhaQ9dmWGsyyQ@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Chris Palmer <palmer@google.com>, Brian Smith <brian@briansmith.org>, Glenn Adams <glenn@skynav.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>

 Just wanted to let you know we revisited this issue at the face to
face meeting at TPAC, as part of closing out all last call comments
for CSP Level 2.

 The consensus of the group was to leave the specification as-is, but
to remove reflected-xss, report-uri, frame-ancestors and sandbox
directives when a policy is set via a meta tag.

 The minuted discussion on the topic can be found at:


-Brad Hill

On Wed, Jun 18, 2014 at 12:18 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
> On 6/16/2014 11:33 AM, Chris Palmer wrote:
>> Another solution floated was to have the security policy expressed as
>> the resource retrieved from a well-known URI, rather than mashing it
>> in headers. Then it could be cached and pre-fetched.
> A well-known location means an entire site has to have the same policy
> which leads to a weak policy, but early versions of the spec (and
> Mozilla's original implementation) did support a header-specified policy
> URL for that reason. If a large chunk of your site uses the same policy
> then it's cached and fast; if one page needed a unique policy you can do
> that, too.
> -Dan Veditz
Received on Tuesday, 4 November 2014 23:04:06 UTC

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