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

Re: Proposal: A pinning mechanism for CSP?

From: Jim Manico <jim.manico@owasp.org>
Date: Fri, 23 Jan 2015 10:34:00 -0800
Message-ID: <-3651092070660257469@unknownmsgid>
To: Brad Hill <hillbrad@gmail.com>
Cc: Mike West <mkwst@google.com>, 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>
Oh course the risk of allowing a per-page/per-response header that
over-rides a "manifest" like pinning config is that response splitting and
similar could over-ride the initial pin. Which is riskier, Brad? I'm not

>From a dev easy-of-use perspective, the header over-ride is ideal.

Jim Manico
(808) 652-3805

On Jan 23, 2015, at 10:29 AM, Brad Hill <hillbrad@gmail.com> wrote:

>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:34:30 UTC

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