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

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.

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?

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

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

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.

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.

Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.

I think popularity, from most to least?

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.