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 certain. >From a dev easy-of-use perspective, the header over-ride is ideal. -- Jim Manico @Manicode (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 perspective. -Brad
Received on Friday, 23 January 2015 18:34:30 UTC