- From: Brian Smith <brian@briansmith.org>
- Date: Fri, 6 Feb 2015 10:14:47 -0800
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, yan zhu <yan@mit.edu>, Chris Palmer <palmer@google.com>, Ryan Sleevi <sleevi@google.com>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>
Mike West <mkwst@google.com> wrote: > Feedback would be quite appreciated. If there's enough interest (and folks > don't think the idea is insane), I'll clean up the doc a bit more and see if > we can push it out as a FPWD. Isn't this better done as a feature of web servers than a feature of web browsers? In most web servers I've used, it is trivial to configure them to either (a) add the same header to every response, or (b) use a default value for a header in a response if the header wasn't already set by the back end. It seems like we could simply add a recommendation to the CSP spec to do this, and be done. HSTS and HPKP have pinning because it is necessary for them to work, because they fundamentally affect whether or not to trust content from the server. But, CSP operates after trust has been established (perhaps poorly, in the case of non-HTTPS resources), so that's not a factor here. The DoS potential of HPKP pinning seems like it would apply to CSP pinning too. Regarding signed apps, Mozilla's signed packaged app mechanism and Chrome's similar mechanism (for extensions, at least) provides a way to specify the CSP in the manifest. I don't believe that signed web apps make sense without a manifest. (I designed and implemented Mozilla's packaged app signing, so I may be biased.) HTTP/2's header compression means that you'll only be sending one copy of each unique CSP header field per connection, for the most part. Anyway, I think default CSPs are a great idea but I don't think it's the browsers' job to manage that. Considering that there's already a way to accomplish this with existing tools, and considering there are (IMO) more important WebAppSec problems to solve (e.g. <script src=http://third-party.example.com/insert-widget.js>), this seems like something that might be better to avoid, at least for now. Cheers, Brian
Received on Friday, 6 February 2015 18:15:14 UTC