W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2012

Re: CSP 1.1: Paths in source list definitions.

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Mon, 15 Oct 2012 16:15:22 +0200
To: "Mike West" <mkwst@google.com>, "Adam Barth" <w3c@adambarth.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "Tanvi Vyas" <tanvi@mozilla.com>, dveditz@mozilla.com
Message-ID: <op.wl74jwla49xobu@odinho-fido.oslo.osa>
On Sat, 13 Oct 2012 09:56:35 +0200, Adam Barth <w3c@adambarth.com> wrote:

>> One open question is how we would handle query strings. Do we want to
>> support 'example.com/js/thisfile.js?id=2'? If so, how would we handle a
>> request for 'example.com/js/thisfile.js?extra=param&id=2'? Is that a  
>> match?
>> How about 'example.com/js/thisfile.js?id=2&extra=param'?
> IMHO, we shouldn't support query strings.  This feature is most useful
> for restricting to a known-safe directory.

What do you mean? Should not support query strings, as in:

   example.com/js/thisfile.js?id=2

would be blocked, when CSP allows /js/thisfile.js?

That does make sense, however: query strings are often used to bust the  
cache when you do updates to static resources. So you would presumably  
allow /js/thisfile.js?28 and then when you update it it changes to  
/js/thisfile.js?29 ?

I'm totally fine with that. Actually using full paths  
(http://example.com/js/thisfile.js) rather than the full folder  
(http://example.com/js/), or even the origin itself (http://example.com)  
are a sign of OCD anyway - so if you specify a file it would make sense  
for it to only be called like that.

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Monday, 15 October 2012 14:16:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 15 October 2012 14:16:14 GMT