Re: Proposal: A pinning mechanism for CSP?

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