W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: Proposal: A pinning mechanism for CSP?

From: Brad Hill <hillbrad@gmail.com>
Date: Fri, 23 Jan 2015 18:29:49 +0000
Message-ID: <CAEeYn8jJWnBT-2ne39wXNEp8UwbJ3zvJ=Fmp51harmioFeHS7w@mail.gmail.com>
To: Mike West <mkwst@google.com>, Jim Manico <jim.manico@owasp.org>
Cc: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, yan zhu <yan@mit.edu>, Chris Palmer <palmer@google.com>, Ryan Sleevi <sleevi@google.com>, Dan Veditz <dveditz@mozilla.com>
>The pinning model in the proposal uses the existing
> combination logic for multiple headers: resources simply
> need to pass all the policies applied to a protected resource.
> I think overriding the pinned policy completely would undermine
> its impact to some extent; I'd prefer to avoid doing that unless
> there's a good reason to.

I don't know about that.  I like the idea of "here's a backup policy in
case things go wrong and we forget to send one".  For example, if an
application ends up returning an error page before the logic that applies
the policy was reached.

But it seems very likely that a large application or set of applications
hosted at a domain will have one or two things that need an exception,
(gotta eval this one thing, I promise I triple-audited the code) and
setting an explicit header seems like a good escape hatch here.

Also, things like "Do I support HTTPS" and "Who is my CA" are pretty
large-granularity things in a site's lifecycle that are unlikely to change
very often.  CSP policies are fine-grained and intimately related to
application logic that has a very high update velocity.  A "first pin wins"
policy is *much* more risky than these other technologies from that

Received on Friday, 23 January 2015 18:30:17 UTC

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