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-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.

Of course they are all worth looking at. Scott's header test (https://securityheaders.io) is a great check for your own sites.

> I've found the X-Frame-Options (to prevent clickjacking via iframe)

I wish some way existed to prevent clickjacking (e.g. via invisible iframe) without actually banning frames. There are useful applications for framing another site that can't be achieved by any other means, apart from writing a browser extension. And framing a site without making it invisible seems like unfortunate collateral damage.

Dan Kaminsky is working on something: http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickja...

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!

Some day that will probably happen, but of course the issue is that it would break every site that relies on the less secure behavior.

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?

Idlewords runs Pinboard, a bookmarking site, so I'm guessing he's worried about the impact of other people turning on CSP. I don't use Pinboard, but I believe I've encountered the problem using the Instapaper bookmarklet.

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.

But there is only so much you can do with headers, the real risks are in the documents themselves.

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 only work in the primary document.

> How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags.

But wouldn't folks still be able to inject scripts by just writing `</nojs><script>alert('hi')</script><nojs>`?

CSP does exactly that; you can just ban inline scripts entirely.

For people using Node/Express, Helmet is a useful little library that lets you add these security headers and CSP pretty easily: https://github.com/helmetjs/helmet

This is the counterpart for Ruby: https://github.com/twitter/secureheaders

Lusca[1] is the NPM module for use with Express that comes in the KrakenJS middleware (open sourced by PayPal).

    app.use(lusca.csrf());
    app.use(lusca.csp({ /* ... */}));
    app.use(lusca.xframe('SAMEORIGIN'));
    app.use(lusca.p3p('ABCDEF'));
    app.use(lusca.hsts({ maxAge: 31536000 }));
    app.use(lusca.xssProtection(true));

[1] https://github.com/krakenjs/lusca

This post encouraged me to go through my own website and add a moderately strict CSP header, sans 'unsafe-inline' scripts/styles. Thanks!

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.

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.

> 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 can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.)

But the refactoring is well worth doing. By eliminating inline JavaScript and off-domain JavaScript, you eliminate the possibility of script injection. And directly including third-party JavaScript (or CSS, which can include JavaScript) opens you up to various kinds of attacks.

> 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'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.

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.

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.

You also need that module to do per URI/path/regex match headers properly, because add_header + location blocks are woefully insufficient thanks to the way they are processed. This is one reason I gave up on CSP under nginx.

Server: header makes people gone mad?

It wastes space, and reveals unnecessary information about your server infrastructure.

As if turning it off helps. Nginx is so popular, attackers would just try Nginx-specific exploits right after trying Apache ones even if they don't know for sure whether you are running Nginx.

Can you help me understand the graphs? What is being plotted on the X axis?

I think popularity, from most to least?

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.

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?

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.