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.<p>For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Security-Policy (to restrict eval, inline JS, JS and embed sources and more) to be the most useful headers by far. If you can run CSP without 'unsafe-eval' or 'unsafe-inline' and restrict all sources to your local domain, your site's security will be much better for it as an entire range of attacks is eliminated on modern browsers.<p>Of course they are all worth looking at. Scott's header test (<a href="https://securityheaders.io" rel="nofollow">https://securityheaders.io</a>) is a great check for your own sites.
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.<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=866522" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=866522</a>
HN uses x-frame-options:"DENY" to good effect which takes care of a fair number of click-jack tricks, it also uses strict-transport-security.<p>But there is only so much you can do with headers, the real risks are in the documents themselves.<p>How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags. And those tags should <i>only</i> work in the primary document.
For people using Node/Express, Helmet is a useful little library that lets you add these security headers and CSP pretty easily: <a href="https://github.com/helmetjs/helmet" rel="nofollow">https://github.com/helmetjs/helmet</a>
This post encouraged me to go through my own website and add a moderately strict CSP header, sans 'unsafe-inline' scripts/styles. Thanks!
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.
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?
I'd really like to know if any of you have used the report feature. It seems like any report you got would show you a bug in your code. What were the bugs? How many reports did you get?