[STRML]

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.

[JoshTriplett]

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

[hannob]

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

[Scott_Helme_]

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!

[eli]

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.