21–30 of 36 posts
I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites. For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Securi…
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!
This post encouraged me to go through my own website and add a moderately strict CSP header, sans 'unsafe-inline' scripts/styles. Thanks!
It's free to sign up and use.
Earlier quoted context omitted.
> There's no way to whitelist inline code That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header. It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.
Ah. I hadn't found that in Mozilla's CSP documentation. Thanks.
I gone through his previous blog post and found the changing Server: header field. Why have to waste time for rebuilding nginx from source for that? Why not just insert 'server_tokens off' in your nginx.conf?
Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
CSP breaks bookmarklets in Firefox, which makes it rather user-hostile. This is properly Mozilla's fault, but they've shown no interest in fixing it. https://bugzilla.mozilla.org/show_bug.cgi?id=866522
I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
You might find the Content-Security-Policy-Report-Only header useful for identifying CSP issues and deploying policies without actually blocking anything.
Earlier quoted context omitted.
Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
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.
CSP breaks bookmarklets in Firefox, which makes it rather user-hostile. This is properly Mozilla's fault, but they've shown no interest in fixing it. https://bugzilla.mozilla.org/show_bug.cgi?id=866522
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?