Scott_Helme_

You can also pin the public keys of certificate authorities to limit which ones can issue for your domain and not have to worry about key backups. GitHub do this as you can see here: https://report-uri.io/home/pkp_analyse/https%3A%2F%2Fgithub....

I also have a blog on the various places you can pin like the leaf, intermediate and root: https://scotthel.me/k2h

Did that fix it? Failing that, do you have any extensions or other things that might affect this?

Interesting, what version of Firefox is this? You can see in the CSP that 'self' is a defined keyword for both the script-src and style-src directives: https://report-uri.io/home/analyse/https%3A%2F%2Fsecurityhea...

Exactly right. The only browser that will send HPKP reports right now is Chrome and that was very recent.

No, but that doesn't impact the operation of enforcing the use of their public keys which is the main purpose. It's definitely preferable to have reporting though.

There's also https://starttls.info/ which will check mail server configurations.

A lot of advice online, including my own, recommends that once you start enforcing a policy you keep the max-age quite short for a period of time. The report-only mode is helpful in identifying issues but given the nature of what HPKP is and does, jumping straight to a high max-age value when you start enforcing the policy isn't wise.

I agree, hopefully the majority will see benefit in it. It's intended as more of a way to educate rather than a definitive security assessment.

Glad it could help!

To be honest, most of the reports I get for my sites aren't legitimate issues. Malware on the endpoint makes changes to pages (like inserting ads) that generate reports, certain browser features trigger changes that cause reports. There are also browser plugins and addons that make changes which also cause reports to be sent. You can always create a report only CSP which will send reports but not block actions on the page and use my service at https://report-uri.io to gather the reports for you to look at them. All free and no risk of breaking anything, if you're interested.

Yes, sorry that wasn't clear. I scanned the sites in groups of 4,000. The x axis is each group in descending order from the top of the Alexa list to the bottom.

Interesting, I don't use Firefox enough to have noticed this. Would it be possible to whitelist this functionality in your CSP in the short term without adversely affecting the strength of your policy?

Sadly nly is right. The only other option to change this is the ngx_headers_more module, but that still requires a rebuild. I suppose that way you at least get a little more functionality for your troubles.

I'm going to be doing some blogs in the coming weeks on how to use hashes and nonces to whitelist inline script. Hopefully, this will make introducing CSP a little easier. I also have some tools in the making that will help in this regard too.

If you like, you could also add reporting to your CSP and get live feedback on it with https://report-uri.io

It's free to sign up and use.

It's worth pointing out that you can replace the functionality of the X-Frame-Options header with Content-Security-Policy using the frame-ancestors directive if you want to: https://scotthelme.co.uk/csp-cheat-sheet/#frame-ancestors

A world with opt-in to unsafe behaviour would be great, but a long way off I fear. Thanks for mentioning the header check service!