W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2017

Re: Add ability to specify the version of used CSP

From: Bil Corry <bil@corry.biz>
Date: Thu, 9 Mar 2017 07:43:42 -0700
Cc: WebAppSec WG <public-webappsec@w3.org>
Message-Id: <41381B3B-92E0-45E9-AD1F-B9CA55A48806@corry.biz>
To: Taras Ivashchenko <oxdef@yandex-team.ru>
Back in 2008, I provided feedback on a newly proposed CSP specification.  My very first item addressed a shortcoming regarding CSP versioning.

I suggested the client send a header with the version of CSP it supports (if any), and the server could then respond with the CSP header for that version (or make other security choices).

I even called out that it would be better than having multiple CSP headers expressed by the server, e.g.

        X-Content-Security-Policy: ...
        X-Content-Security-Policy2: ...
        X-Content-Security-Policy3: ...
        X-Content-Security-Policy4: ...
        X-Content-Security-Policy5: ...

Instead, the spec omitted a versioning scheme, perhaps because some believed that there would never be a version 2 of CSP.

The entire thread is here and makes for interesting reading, given what we know today:


- Bil

> On Mar 9, 2017, at 2:01 AM, Taras Ivashchenko <oxdef@yandex-team.ru> wrote:
> Hello!
> It is awkward to maintain backward compatible CSP policy, e.g. keep in it unsafe-inline with nonce for CSPv1 or frame-
> src/child-src. It looks like in the future versions of CSP such problem will be more obvious. 
> In some cases in web application it is easer to have support of only the last one standard. 
> What do you think about adding ability to specify the version of used CSP? 
> It can be done in header name like:
> Content-Security-Policy-v3: ...
> If browser meets more the one CSP header it should use header with the latest support version.
> I had also reported the issue on GitHub but there is no activity in it during 8 days
> https://github.com/w3c/webappsec-csp/issues/189
> -- 
> Taras Ivashchenko
> Information Security Officer,
> Yandex

Received on Thursday, 9 March 2017 14:44:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:00 UTC