Re: Proposal: A pinning mechanism for CSP?

On Fri, Feb 6, 2015 at 7:14 PM, Brian Smith <> wrote:

> Isn't this better done as a feature of web servers than a feature of
> web browsers?

It's certainly something that could be done as a feature of web servers.
However, it's really easy to miss pages. For instance, I just checked, a page that _really should_ have a CSP, as it's
terribly high-value, and the guy responsible for it knows a thing or two
about CSP.

I know it's possible to configure nginx to send proper headers with error
pages, but I didn't do it because I never thought about it until just this
moment. I suspect that other (even _more_ valuable sites) are in similar

Belts and suspenders, right?

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.

We should add that recommendation regardless:

The DoS potential of HPKP pinning seems like it would
> apply to CSP pinning too.

The worst case HPKP failure is a bricked server, as trust can't be
established at all, not even to kill the pin. A pinned CSP doesn't actually
prevent you from talking to the server, so it remains capable of updating a
bad pin (or disabling pinning entirely via `max-age=0`).

> 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=>)

What's the problem to solve in this example?

Mike West <>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Saturday, 7 February 2015 05:27:56 UTC